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Introduction 


The  FAA  Program  Manager's  Guide  provides  the  Program  Manager  (PM) 
with  a  convenient  summary  of  current  information  on  the 
acquisition  process  for  most  FAA  acquisitions.  It  outlines  the 
phases  of  the  acquisition  life-cycle  and  the  acquisition  process 
described  in  Department  of  Transportation  (DOT)  Transportation 
Acquisition  Manual  (TAM)  Chapter  34,  Appendix  A,  Maior 
Acquisition  Policy  and  Procedures,  and  Federal  Aviation 
Administration  (FAA)  Order  1810.1,  Acquisition  Policy. 

TAM  Chapter  34,  Appendix  A,  effective  1  January  1993,  was  a 
complete  revision  to  DOT  major  acquisition  policy  contained  in 
DOT  Order  4200. 14C,  which  has  been  canceled.  The  basic  policy 
for  major  acquisitions  (over  $50  million)  has  not  changed  but  the 
latest  guidance  requires  more  formal  reporting,  documentation  of 
mission  needs  and  plans,  and  specifically  delegates  more 
authority  to  operating  administrations,  such  as  FAA. 

FAA  Order  1810.1  was  completely  rewritten  in  early  1993  to 
include  the  revised  DOT  major  acquisition  policy,  DOT  and  FAA 
policy  on  less  than  major  acquisitions,  and  an  extensive  process 
description  of  the  major  acquisition  life  cycle. 

FAA  major  acquisitions  are  accomplished  with  matrix  management 
that  was  adopted  in  February  1990.  Chartered  by  the 
Administrator,  the  program  manager  is  supported  by  associate 
program  managers  (APMs)  from  contracts,  legal,  test,  logistics 
support  (NAILS) ,  engineering,  systems  engineering,  and  other 
needed  areas.  The  APMs  remain  in  their  functional  organization 
and  are  designated  to  work  on  one  or  more  programs  according  to 
agreements  made  between  their  functional  organization  and  the 
PMs .  In  many  cases  the  agreements  are  made  in  writing  as  program 
directives . 

Program  directives  (PDs)  describe  tasks  to  be  performed,  products 
to  be  delivered,  time  schedules  with  milestones,  and  resource 
requirements,  which  assist  the  PM  in  planning  and  managing  the 
program.  PDs  commit  the  supporting  organization  to  satisfactory 
completion  of  agreed-upon  tasks  within  the  allotted  timeframe. 

The  PM  is  responsible  for  the  complete  management  of  program 
directives,  which  includes  periodic  review  of  program  directive 
accomplishments,  and  tracking  of  program  resources  already 
allocated.  The  PM  is  also  responsible  for  final  review  and 
approval  of  all  tasks  and  products. 
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The  program  manager  is  responsible  for  the  following: 


1.  Presenting  and  defending  the  program  to  the  Acquisition 
Review  Committee  (ARC)  or  the  Transportation  Systems 
Acquisition  Review  Council  (TSARC)  at  each  KDP 

2 .  Preparing  program  documentation  and  updating  same 
before  each  key  decision  point  (KDP) .  Documentation 
includes  cost/benefit  analyses  (CBA) ,  life— cycle  cost 
(LCC)  estimates,  mission  need  statements  (MNSs) ,  and 
acquisition  plans,  among  others. 

3.  Executing  the  program  as  approved  at  each  KDP 

4.  Reporting  on  program  status  at  major  acquisition 
reviews  scheduled  by  the  Executive  Director  for 
Acquisition,  AXQ— 1 

5.  Preparing  a  Test  and  Evaluation  Master  Plan  (TEMP)  at 
program  initiation  and  updating  it  at  each  KDP.  This 
is  coordinated  with  the  program  sponsor,  and  approved 
by  the  Test  Policy  Review  Committee  (TPRC) . 

Although  the  Program  Manager's  Guide  deals  primarily  with 
National  Airspace  System  (NAS)  programs,  programs  for  providing 
systems,  equipment  or  services  that  are  not  part  of  the  NAS 
presently  exist  and  PMs  may  encounter  others  in  the  future. 
Program  managers  have  the  flexibility  to  modify  documentation  for 
programs  as  defined  by  approved  acquisition  and  program 
management  plans.  Test  procedures  for  non-NAS  programs  differ 
from  those  used  in  NAS  programs. 

This  Program  Manager's  Guide  does  not  change  or  replace  existing 
notices,  orders,  or  other  directives,  and  does  not  include  every 
topic  or  document  a  program  manager  will  need  to  consider. 
Chapters  in  the  Guide  are  arranged  roughly  in  the  approximate 
order  of  events  as  they  occur  in  the  process.  Ghapters  were 
written  by  subject  matter  experts  as  identified  on  pages  iv  and 
V.  Acronyms  and  abbreviations  may  be  identified  in  the 
alphabetical  list  provided  in  Appendix  B. 
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ACQUISITION  LIFE-CYCLE 


MISSION  NEED  ANALYSIS 
MISSION  NEED  STATEMENT  (MNS) 


COMPARATIVE  ANALYSES  (RISK.  COST.  PERFORMANCE.  SCHEDULE.  BTC-) 

UPDATE  MISSION  NEED  STATEMENT  (MNS)  IN  m  AL  TEST  AND  EVALUATION 

ACQUISITION  PLAN  (AP)  MASTER  PLAN  (TEMP) 

BUDGETING/SCHEDUUNG  DRAFT  SYSTEM  SPECIFICATION 

INITIAL  PROGRAM  MASTER  PLAN  (PMP)  INITIAL  ILS  PLAN 

INITIAL  PROGRAM  IMPLEMENTATION  AGENCY  PROCUREMENT  REQUEST 

PLAN  (PIP) 


EMQNSTRATIONA^ALIDATIQN 


(RISK  REDUCTION) 

UPDATE  MNS/AP/TEMP/PMP/PIP/ILSP  REFINE  FINANCIAL  PLANNTNG/SCHEDULIN( 
CONDUCT  RISK  REDUCTION  CONDUCT  DEMONSTR  ATIONA^ALIDATION 


UPDATE  AP/MNS/TEMP/PIP/ILSP  DETAILED  PLANNING 

CONDUCT  FSD  CONTRACT 


UPDATE  AP 

CONDUCT  DRR 

PRODUCTION  CONTRACT 

ACQUIRE  REAL 

DETAILED  PRODUCTION  PLANNING 

PROPERTY 
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Chapter  1 


Acquisition  Ileview  And  Approval  ' 


This  chapter  provides  a  reference  guide  to  acquisition 
activities.  The  following  topics  are  presented: 

O  Major  acquisitions  and  the  development  of  mission  need 
statements  (MNSs) 

o  Approval  of  MNSs  and  acquisition  plans  at  key  decision 
points  (KDPs) 

O  Administrator's  program  review 

o  Advanced  planning  and  annual  procurement  plans 

o  Acquisition  plans 

o  Delegation  of  procurement  authority 

o  Procurement  requests 

o  Independent  cost  estimates 

o  Acquisition  streamlining 

o  Competitive  source  selection  process 

o  Non-competitive  procurement 

o  Small  and  disadvantaged  business  procurement 

o  Sample  procurement  lead-time  schedules 

Process  Description 

A  generic  description  of  the  life  cycle  of  a  NAS  system  is  shown 
in  Figure  1.1  on  page  1-12. 

Major  Acquisitions  and  Development  of  Mission  Need  Statements 

Transportation  Acquisition  Manual  (TAM)  Chapter  34,  Appendix  A 
"Major  Acquisition  Policies  and  Procedures",  provides  the 
framework  for  the  review  and  approval  of  major  acquisitions.  FAA 
Order  1810.1,  Acquisition  Policy,  provides  specific  FAA  review 


and  approval  procedures  for  both  major  and  less  than  major 
acquisitions . 

Major  acquisitions,  which  are  critical  to  fulfilling  an  agency 
mission,  entail  the  allocation  of  large  resources  and  warrant 
special  management  attention.  They  are  defined  in  TAM  Chapter 
34,  Appendix  A  as  Levels  I,  ri,  and  III. 

Level  I:  A  level  I  major  acquisition  program  is  defined  by  TAM 
Chapter  34,  Appendix  A  as: 

o  A  program  exceeding  $150M  in  total  acquisition  cost 

o  A  program  upgraded  from  a  Level  III 

o  A  program  otherwise  designated  as  Level  I  by  the  DOT 
Acquisition  Executive 

Level  II:  A  Level  II  major  acquisition  program  generally  is  for 
services.  Level  II  major  acquisition  programs  are  defined  as: 

o  A  program  to  acquire  services  exceeding  $150M  in  total 
acquisition  cost 

o  A  program  upgraded  from  a  Level  III 

o  A  program  otherwise  designated  as  Level  II  by  the  DOT 
Acquisition  Executive 

Level  III:  A  Level  III  major  acquisition  program  is  for  the  same 
types  of  items,  systems  or  services  covered  under  Level  I  or  II 
except  it  is  not  as  complex  or  costly.  Level  III  major 
acquisition  programs  are  defined  as: 

o  Generally  a  program  between  $50M  and  $150M  in  total 
acquisition  cost 

o  A  program  downgraded  from  a  Level  I  or  II 

o  A  program  otherwise  designated  as  Level  m  by  the  DOT 

Acquisition  Executive 

After  designation  as  a  Level  HI  program  by  the  DOT  Acquisition 
Executive,  these  programs  are  further  designated  as  Level  IIIA 
for  items  and  systems  or  Level  TUB  for  services. 

The  FAA  has  added  Level  IV  acquisitions  for  the  same  types  of 
items,  systems  or  services  as  Level  I,  II,  or  III  acquisitions 
except  total  acquisition  cost  is  less  than  $50  million. 
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To  be  considered  a  major  acquisition,  the  project  must  be 
formally  designated  as  a  major  acquisition  by  the  Deputy 
Secretary,  DOT'S  Acquisition  Executive. 

Those  systems  designated  as  major  acquisitions  follow  the 
structured  acquisition  process  established  in  0MB  Circular  A— 109 
(tailored  to  individual  programs)  .  This  process  begins  with  the 
development  and  approval  of  a  mission  need  statement.  Guidance 
for  the  preparation  of  MNSs  is  contained  in  Order  1810.1.  MNS 
development  and  approval  is  followed  by  a  concept  exploration 
phase  that  often  results  in  a  more  specific  definition  of 
requirements.  This  in  turn  is  followed  by  a  demonstration/ 
validation  phase  and  then  a  full  scale  development  phase.  The 
production  and  deployment  phase  results  in  commissioning  the 
product  in  the  NAS  or  other  program  or  mission  area.  Both  DOT 
and  FAA  policy  require  the  tailoring  of  this  process  so  that  only 
the  appropriate  essential  activities  and  phases  are  conducted. 
Approval  of  the  appropriate  acquisition  executive  is  provided  at 
each  key  decision  point  to  combine  phases  and  tailor  the  process 
for  each  program. 

The  four  key  decision  points  (KDPs) ,  that  require  the  approval  of 
MNSs  and  acquisition  plans,  are  as  follows: 

o  KDP  I  -  authorizes  the  program  to  proceed  with  the 
concept  exploration  phase 

o  KDP  II  -  authorizes  the  program  to  proceed  with  the 
demonstration/validation  phase 

o  KDP  III  -  authorizes  the  program  to  proceed  with  full- 
scale  development 

o  KDP  IV  -  authorizes  the  program  to  proceed  with 
production  and  deployment  of  the  system 

0MB  Circular  A— 109  establishes  policies  to  be  followed  by 
executive  branch  agencies  in  the  acquisition  of  major  systems. 

It  requires  each  department  to  appoint  an  acquisition  executive 
to  be  the  focal  point  for  approval  of  major  acquisition 
activities  at  KDPs.  The  circular  defines  the  system  acquisition 
process  as  "A  sequence  of  acquisition  activities  starting  from 
the  agency's  mission  need,  with  its  capabilities,  priorities  and 
resources,  extending  through  introduction  into  use  or  successful 
achievement  of  program  objectives". 

Approval  for  Level  I  and  II  major  acquisitions  is  given  by  the 
DOT  Acquisition  Executive  (Deputy  Secretary)  and  approval  for 
Level  III  major  acquisitions  is  given  by  the  FAA  Acquisition 
Executive  (Executive  Director  for  Acquisition)  .  For  Level  Ills, 
MNS  approval  is  required  from  the  Office  of  the  Secretary  before 
the  program  is  initiated.  The  FAA  Acquisition  Executive  approves 
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MNSs  for  Level  IV  programs,  but  all  other  acquisition  executive 
functions  are  performed  by  the  associate  administrator  of  the 
performing  organization. 

Approval  of  Mission  Need  Statements  and  Acquisition  Plans  at  Key 
Decision  Points 

Before  initiating  a  program  that  is  in  the  Capital  Investment 
Plan  (CIP) ,  you  must  obtain  approval  from  the  FAA  Acquisition 
Executive  and  from  the  DOT  Acquisition  Executive,  as  appropriate. 
This  includes  approval  of  mission  need  statements,  acquisition 
plans  and  source  selection  plans.  These  documents  must  be 
updated  periodically. 

Before  seeking  approval  from  the  DOT  Acquisition  Executive  at  a 
KDP,  the  FAA  consults  the  Acquisition  Review  Committee  (ARC)  to 
decide  whether  the  program  is  ready  to  proceed.  The  Program 
Manager  presents  the  status  of  the  program  to  this  group  using  a 
briefing  format  that  is  available  from  the  Office  of  Acquisition 
Policy  and  Oversight  (ACQ-1)  . 

For  programs  designated  as  major  acquisitions,  the  FAA 
Acquisition  Executive  chairs  the  Acquisition  Review  Committee. 

The  FAA  Acquisition  Executive  either  approves  transition  to  the 
next  level  of  development  for  Level  III  major  acquisitions  or, 
approves  the  FAA  request  for  Deputy  Secretary  approval  of  Level  I 
or  Level  II  major  acquisitions. 

Administrator'  s  Program  Reviews 

Programs  designated  for  special  management  attention  are 
periodically  reviewed  by  the  Administrator  using  a  briefing 
format  that  is  available  from  ACQ-1.  See  Chapter  21  for  details 
on  these  reviews  under  "Major  System  Acquisition  (MSA)  Reviews". 

Advanced  Planning  and  Annual  Procurement  Plans 

Federal  Acquisition  Regulations,  Part  7,  and  DOT  Order  4200. 16A, 
Advance  Acquisition  Planning  and  Annual  Procurement  Plan,  are  the 
basic  directives  that  describe  responsibilities  and  procedures 
for  the  planning  that  precedes  contracting  for  goods  and 
services .  The  DOT  order  requires  the  FAA  to  develop  an  Annual 
Procurement  Plan.  This  plan  includes  all  proposed  procurements 
exceeding  $2M,  and  all  proposed  service  contracts  costing  more 
than  $200,000  and  determined  to  be  advisory  and  assistance 
services.  Before  any  procurement  meeting  these  criteria  can 
proceed  (i.e..  Commerce  Business  Daily  synopsis,  release  of  a 
solicitation  for  a  contract,  or  issuance  of  an  inter-agency 
agreement),  it  must  be  included  in  the  current  plan.  The  FAA 
Administrator  usually  approves  the  Procurement  Plan  annually  by 
May  15  to  authorize  initiation  of  all  anticipated  procurements  in 
the  upcoming  fiscal  year.  The  latest  plan  is  maintained  in  the 
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Office  of  Acquisition  Support  (ASU-lOO) ,  and  an  information  copy 
is  provided  to  OST.  Planning  for  lower  dollar  procurements 
(between  $200,000  and  $2,000,000)  is  conducted  by  ASU-300  and 
regional  and  center  procurement  offices. 

The  plan  is  reviewed  and  updated  at  least  quarterly.  The  updated 
plan  is  approved  by  the  Administrator  and  information  copies  are 
forwarded  to  DOT'S  Office  of  Acquisition  and  Grant  Management  (M- 
60)  and  Office  of  Small  and  Disadvantaged  Business  Utilization 
(S— 40)  within  five  working  days. 

The  program  manager  must  provide  information  on  all  planned 
procurements  or  inter-agency  agreements  that  meet  the  plan's 
dollar  thresholds.  Anticipated  individual  tasks  or  delivery 
orders  and  options  do  not  need  to  be  listed  separately,  if  the 
total  estimated  dollar  value  and  the  description  of  the 
procurement  action  includes  them. 

Acquisition  Plans 

Acquisition  plans  are  prepared  following  guidelines  available 
from  ACQ— 1  for  all  major  acquisitions  designated  by  the  DOT 
Acquisition  Executive.  Acquisition  plans  may  also  be  required  at 
lower  levels  at  the  discretion  of  FAA  officials.  Acquisition 
plans  must  be  approved  by  the  FAA  or  DOT  Acquisition  Executive 
(as  appropriate)  before  initiating  any  procurement  action,  though 
draft  solicitations  and  similar  material  can  be  released  before 
acquisition  plan  approval  with  the  concurrence  of  ASU— 1 . 
Acquisition  plans  must  be  updated  annually,  whenever  there  is  a 
major  change  in  the  program,  and  at  KDPs.  The  requirement  to 
have  acquisition  plans  for  programs  below  $50M  is  actively  being 
considered . 

Delegation  of  Procurement  Authority 

Whenever  the  FAA  needs  to  procure  federal  information  processing 
(FIP)  resources  or  services,  the  Federal  Information  Resource 
Management  Regulation  (FIRMR)  requires  that  an  agency  procurement 
request  (APR)  for  a  delegation  of  procurement  authority  (DPA)  be 
submitted  to  the  General  Services  Administration  (GSA) .  The 
purpose  of  the  APR  submission  is  to  obtain  delegation  of  GSA' s 
single  procurement  authority  for  FIP  resources  or  services  other 
than  those  provided  in  GSA  multiple  award  schedule  contracts  or 
blanket  delegations. 

The  FIRMR  is  the  primary  source  document  for  complying  with  these 
requirements . 

Analyses  and  studies  supporting  the  acquisition  of  FIP  resources 
must  be  done  sufficiently  ahead  of  the  actual  procurement  date  to 
minimize  delays  in  obtaining  a  delegation  of  authority.  The 
preparation  and  approval  process  can  range  from  twenty-seven  (27) 


to  thirty— five  (35)  weeks  depending  on  the  studies,  analyses,  and 
justifications  required.  Most  documentation  activities  can  be 
accomplished  in  parallel. 

The  PM  is  responsible  for  preparing  the  APR.  He/she  reviews  the 
APR  strategy  with  AIT— 340,  and  the  Information  Systems  Management 
Division  (M-32)  before  beginning  work  to  verify/identify  specific 
requirements .  Early  planning  will  avoid  delays  and  problem 
areas.  A  briefing  to  OST  and  GSA  can  hasten  the  review  process 
by  presenting  the  essential  facts  and  providing  the  opportunity 
for  reviewers  to  meet  FAA  PMs *  The  Director,  Office  of 
Acquisition  Support  (ASU)  requires  that  formal  approval  of  APRS 
be  obtained  before  ASU  acts  on  a  procurement  request  (PR) . 

For  large  programs,  the  completed  APR  package  is  submitted  from 
the  appropriate  associate  administrator  to  AIT-1,  who  determines 
the  order  of  review  and  sends  it  to  ASU,  appropriate  Office  of 
the  Assistant  Administrator  for  Information  Technology  (AIT) 
staff,  and  ACQ— 1  for  review  and  approval.  The  DOT  Office  of 
Information  Resource  Management  (M— 30)  will  contact  the  program 
office  to  arrange  any  briefings  to  the  Office  of  the  Secretary  of 
Transportation,  if  required.  The  package  is  submitted  to  GSA  by 
M-1 .  Figure  1.2  summarizes  acquisition  coordination  and  approval 
thresholds . 

Lack  of  early  planning  is  most  often  the  cause  of  delays  and 
problems.  The  package  can  be  complex  and  have  many  components. 
AIT  and  M— 30  can  help  identify  requirements  for  specific 
projects.  Early  planning  is  essential.  A  new  document.  Guide  to 
the  Preparation  of  Agency  Procurement  Requests,  is  available  from 
AIT— 340.  Also,  see  Chapter  22  of  this  Guide  for  a  summary. 

Procurement  Requests  and  Independent  Cost  Estimates 

Each  requiring  office  must  prepare  a  PR  in  order  to  initiate 
contracting  action.  For  larger  projects,  allow  6—12  months 
before  the  planned  date  of  solicitation  release  to  accomplish  the 
following : 

o  Specification  approval 

o  Preparation  and  internal  coordination  of  the  draft  PR 

o  Industry  comments  on  the  draft  specification,  and  draft 
solicitation,  if  required 

ASU  generally  requires  that  PRs  for  major  NAS  or  non— NAS 
projects,  subsystems  and  components  reach  them  at  least  twelve 
(12)  months  before  the  needed  contract  award  date.  The  PR  should 
include  options  for  out-year  requirements,  where  appropriate,  to 
reduce  the  need  for  future  contract  actions,  particularly  for 
non-competitive  procurements. 


An  independent  Government  cost  estimate  is  required  for  every  PR. 
Cost  information  should  be  broken  down  to  the  lowest  level 
possible.  The  contracting  officer  can  provide  samples. 

When  funds  will  be  transferred  to  another  agency  (e.g.,  the 
National  Aeronautics  and  Space  Administration  (NASA)  or  the 
Department  of  Defense  (DOD) ) ,  the  program  manager  should 
coordinate  with  the  contracting  officer  as  early  as  possible  in 
the  process  to  ensure  that  all  appropriate  approvals  are 
obtained.  The  FAA  Acquisition  Manual  Subchapter  1204.70, 
Preparation,  Approval  and  Processing  of  Procurement  Requests,  is 
the  guidance  for  preparing  procurement  requests.  Copies  may  be 
obtained  from  ASU-100. 

Acquisition  Streamlining 

Acquisition  streamlining  can  reduce  the  time  necessary  to  award 
contracts  and  improve  the  quality  of  contract  documents. 
Streamlining  includes  the  following: 

o  Reviewing  draft  solicitations  to  eliminate  counter¬ 
productive  and  over-specified  requirements,  and  obtain 
industry  comments  on  draft  documents 

o  Avoiding  premature  application  of  specifications  and 
standards 

o  Tailoring  specifications  to  eliminate  inadvertent 
establishment  of  requirements  through  indirect 
referencing  of  lower  level  specifications 

o  Including  only  essential  data  requirements  in  the 

Contract  Data  Requirements  List  (CDRL) ,  and  tailoring 
those 

o  Limiting  the  number  of  pages  in  a  solicitation 

o  Limiting  the  number  of  pages  in  proposals  received 

under  a  solicitation 

o  Having  a  small  dedicated  proposal  evaluation  team 

o  Coming  to  an  early  agreement  on  the  logistics  support 
concept 

Competitive  Source  Selection  Process 

Transportation  Acquisition  Manual  Subchapter  1215.6,  Source 
Selection,  establishes  procedures  for  soliciting,  evaluating,  and 
selecting  sources  to  perform  major  negotiated  procurements.  The 
Administrator/Deputy  Administrator  must  approve  a  selection  plan 
for  every  competitively  negotiated  procurement  over  $5M,  and  a 


Source  Evaluation  Board  (SEB)  must  be  used  unless  a  waiver  is 
approved.  The  source  selection  process  is  structured  to  ensure 
the  impartial,  equitable,  and  thorough  evaluation  of  proposals, 
and  to  provide  necessary  data  to  the  source  selection  official 
for  selection  of  that  contractor  who  offers  best  value  to  the 
Government.  The  Administrator  or  another  senior  FAA  official 
acts  as  the  source  selection  official  for  all  FAA  procurements 
subject  to  SEB  requirements. 

A  program  manager  is  responsible  for: 

o  Providing  input  to  ASU-lOO  to  develop  the  Selection 
Plan  which  must  be  approved  before  a  competitive 
solicitation  can  be  issued 

o  Developing  Request  for  Proposal  (RFP)  materials, 

including  the  evaluation  criteria,  in  conjunction  with 
the  contracting  officer 

o  Ensuring  proper  staffing  for  SEB  activities 

o  Complying  with  standards  of  conduct  concerning  SEB 
evaluation  activities 

Non-Competitive  Procurement 

Statutes,  regulations,  and  DOT  and  FAA  policy  require  senior 
management  approval  on  all  procurements  to  be  awarded  non- 
competitively .  A  Justification  for  Other  than  Full  and  Open 
Competition  (JOTFOC)  must  be  approved  by  management  officials  as 
set  forth  in  Transportation  Acquisition  Regulation,  Part  1206.3. 
The  contracting  officer  can  approve  JOTFOCs  up  to  and  including 
$100,000.  The  FAA  Competition  Advocate  (AXQ-1)  approves  JOTFOCs 
from  $100,000  to  $1,000,000.  All  proposed  non-competitive 
procurements  over  $1,000,000  are  approved  by  the  FAA 
Administrator.  Requirements  for  JOTFOCs  and  associated  documents 
are  described  in  FAA  Acquisition  Manual  Chapter  1206.3  issued  as 
FAA  Notices  92-06  and  92-09. 

Prior  to  processing  a  JOTFOC  acquisition,  a  PM  must  provide 
convincing  evidence  that  only  one  supplier  can  meet  the 
Government's  need.  Whenever  successive  purchases  of  identical  or 
related  products  are  anticipated,  the  project  manager  and 
contracting  personnel  should  consider  obtaining  data  and  rights 
to  allow  competitive  re-procurements.  The  PM  is  responsible  for 
providing  persuasive  information  supporting  the  sole— source 
action  asked  for  in  the  PR.  Before  preparing  a  justification, 
informal  coordination  with  ACQ-1  and  ASU-lOO  is  recommended. 

For  recurring  procurements,  the  PM  should  start  with  the  previous 
contract,  identify  the  changes  needed  for  this  procurement,  and 
develop  the  required  documentation  from  this  baseline. 


Small  and  Disadvantaged  Business  Procurement 


For  procurement  through  the  Small  Business  Administration,  called 
Section  8(a)  procurement,  coordination  with  the  Small  and/or 
Small  and  Disadvantaged  Business  Specialist  (ACQ-4)  is  required. 

Current  procurement  regulations  require  all  proposed  procurement 
actions  to  be  reviewed  to  determine  if  they  can  be  set  aside 
exclusively  for  small  business  or  small  disadvantaged  business. 
This  review  is  performed  after  a  procurement  request  is  received 
in  the  contracts  office. 

If  adequate  small  businesses  are  available  to  meet  the 
requirement,  the  procurement  is  set  aside  exclusively  for  small 
business.  If  minority  contractors  certified  by  the  Small 
Business  Administration,  commonly  known  as  Section  8  (a) 
contractors,  are  determined  to  be  able  to  do  the  work,  a 
competitive  or  sole— source  acquisition  is  initiated  to  allow 
these  contractors  to  meet  FAA  requirements.  Recent  changes  in 
procurement  regulations  now  require  competition  for  most  large 
8(a)  procurements  over  $3M  (for  services),  and  over  $5M  (for 
manufacturing) .  With  proper  planning  and  coordination,  smaller 
Section  8 (a)  procurements  can  be  awarded  about  6  months  after 
receipt  of  a  complete  PR. 

Sample  Procurement  Lead-Time  Schedules 

Figure  1.3  shows  a  sample  lead-time  schedule  for  regular 
competitive  procurements.  Figure  1.4  shows  a  sample  schedule  for 
regular  non-competitive  procurement.  Figure  1.5  is  a  sample 
lead-time  schedule  for  8 (a)  negotiated  competitive  procurements 
over  $3M,  and  Figure  1.6  is  a  schedule  for  8(a)  non-competitive 
procurements . 

Contacts 

The  following  staffs  and  divisions  can  assist  with  additional 
information  on  acquisition  review  and  approval: 

0  ACQ— 1  -  Provides  support  in  developing  MNSs  and 
acquisition  plans,  and  provides  information  for 
internal  and  OST  approvals  related  to  the  acquisition 
process 

o  ASU— 100  -  Assists  in  developing  acquisition  and 

selection  plans.  A  specific  contracting  officer  from 
ASU— 300  will  be  assigned  as  the  contracting  officer  for 
the  project  team  in  the  planning,  execution,  and 
administration  of  contracts . 

o  AGC-500  -  Provides  legal  assistance  to  the  Program 
Manager  and  contracting  officer 


O  AIT-300  “  Assists  with  DPAs 

o  The  contracting  officer  assigned  to  each  program  can 
provide  specific  guidance  about  contract  award  and 
administration  matters.  ACQ— 1  and  ASU-lOO  will  provide 
assistance  in  drafting  the  necessary  approval  documents 
as  well  as  coordinating  those  documents  within  FAA  and 
OST. 

Some  specific  contacts  and  telephone  numbers  are: 

o  ASU-120,  202-267-7862,  can  be  contacted  for  assistance 
with  advanced  procurement  planning,  selection  plans, 
and  advanced  procurement  plans 

o  ASU— 300,  202—267—3580,  involves  the  appropriate 

contracting  officer  supporting  each  project  in  the 
planning  effort 

o  ACQ-1,  202-267-8506,  can  be  contacted  regarding  MNSs, 
acquisition  plans,  major  acquisition  reviews,  non¬ 
competitive  procurement  issues,  and  general  planning 
actions 

o  AIT-340,  202-267-9991,  can  be  contacted  regarding  the 
delegation  of  procurement  authority 

o  AXQ— 4,  202—267—8881,  is  the  contact  point  for  the  Small 
Disadvantaged  Business  Program,  including  Section  8 (a) 
contracting 

Reference  Documents 

The  following  document  is  the  basis  for  the  guidelines  presented 
on  delegations: 

o  "Source  Selection  Delegation",  memorandum  from  the 

Secretary  of  Transportation  to  the  Administrator,  dated 
December  20,  1987 

The  following  documents  are  the  basis  for  the  guidelines 
presented  on  acquisition  planning: 

o  DOT  4200. 16A,  Advance  Acquisition  Planning  and  Annual 
Procurement  Plan,  dated  September  6,  1989 


o 


Guide  to  the  Preparation  of  Agency  Procurement  Requests 
(AIT  publication) ,  dated  February  1994 


The  following  documents  are  the  basis  for  the  guidelines 
presented  on  non-competitive  procurement  actions : 


o  Federal  Acquisition  Regulation,  sub-part  6.3 

o  Federal  Acquisition  Regulation  34.001 

o  Transportation  Acquisition  Regulation,  sub-part  1206.3 

o  Order  4405. 6B,  Review  and  Approval  of  Proposed  Other 
Than  Full  and  Open  Competition  Procurements 

The  following  documents  are  the  basis  for  the  guidelines 
presented  on  source  selection: 

o  Transportation  Acquisition  Manual  Sub— chapter  1215.6, 
Source  Selection 

Point  of  Contact  for  Chapter  1  is  Dave  Morissey,  ACQ— 1, 
202-267-3320. 
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FIGURE  1.1 


ACQUISITION  COORDINATION  AND  APPROVAL  THRESHOLDS 


ACTION 

THRESHOID 

FAA  COORDINATION 

FAA  APPROVAL 

OST  COORDINATION 

OST  APPROVAL 

Acquisition  Han 

Level  JV 

1,23.4 

Associate  Administrator 

Level  III 

1.23.4 

Acquisition  Executive 

Copy  to  Deputy  Secretary 

Level  I  and  11 

1.23.4 

Acquisition  Executive 

TSARC  staff 

Deputy  Secretary,  unless 
delegated  lo  M-1 

Selection  Plan 

Over$50M  1,23,4 

As  described  in  approved 

Level  1, 11,  &  III 

Acquisition  Plan 

$5Mto$50M 

Associate  Administrator  of 

performing  organization  identified 
in  Mission  Need  Statement 

Justification  for  Other 
Than  Full  and  Open 

$25  to  $100,000 

1,AGC 

Contracting  Officer 

Competition 

(JOTFOC) 

$100,000  to  SIM 

1,  AGC 

AXQ-1 

OverSlM 

1,2,3,  AGC 

AOA-1 

Mission  Need  All  1,23*4  AOA-I  TS  ARC  staff  S-2  unless  delegated 

Statemenls 


Advisory  and 

Over  $200,000 

1,2,3,  ASU 

AOA-1 

Send  information 

Assistance 

copy  of  Annual 

Services 

Procurement  Plan 

toM-60andS-40 

FIGURE  12 
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ACQUISITION  COORDINATION  AND  APPROVAL  THRESHOLDS  (CONT.) 


ACTION 

THRESHOID 

FAA  COORDINATION 

FAA  APPROVAL 

OST  COORDINATION 

QST  APPROVAL 

Procurement 
Requests 
(first  3 

quarters) 

Under  $25,000 
$25,000  to  5100,000 
$100,000  to  5500,000 
$500,000  or  greater 
Unlimited  for  CIP 
Program 

1  or  lower 

1  or  lower 

1  or  lower 

1  or  higher 

As  appropriate 

1  or  lower 

1  or  lower 

1  or  lower 

1  or  higher 

AOA-I  chartered 
Program  Manager 

Procurement 

Requests 

{4th  quarter) 

$5,000  or  less 

Over  $5,000 

Over  $500,0(X) 

1 

1 

AOA-1  chartered 

Program  Manager 

1  or  lower 

2 

1 

Annual  1,2,3»4  ASU-lOO  AOA-1  Information  copy  to  M- 60 

Procurement  Plan 
(required  March  15 

for  next  FY  for  Interim  updates  require  memo  to  ASU-lOO 

procurements  over  $2M 
except  for  advisory  and 
assistance  services) 


KEY 

1  -  Service  Director 

2  -  Associate  Administrator 

3  -  Executive  Directors 

4  -  Other  Affected  and  3 


If  other  offices  are  involved  or  supplying  funds,  coordination  with  those  offices  is  required  (see  special  requirements  for 

training,  conference  space,  audio  visual,  NAILS,  advisory  and  assistance  services,  contracting  with  DOT  and  former  DOT  employees). 


FIGURE  1.2 


SAMPLE  PROCUREMENT  LEAD-TIME  SCHEDULE  FOR 
MAJOR  DOLLAR  VALUE  COMPETITIVE  PROCUREMENT 


The  following  steps  apply  to  procurements  estimated  to  cost  $50M  or 
more,  to  be  awarded  competitively,  and  to  exclude  8(a)  procedures. 
Historically,  it  has  taken  ASU  9  to  14  months  after  receiving  a  PR 
to  award  a  major  production  contract. 

Program  Manager  Lead  Responsibilities  Pre— Procurement  Steps 

1.  Prepare  draft  specifications  and  obtain  approvals 

2 .  Acquire  industry  comments  on  draft  specifications 

3.  Prepare  a  NAS  Change  Proposal  (NCP) ,  if  necessary,  and  obtain 
approval 

4.  Prepare  a  PR,  obtain  internal  approvals,  and  submit  to  ASU 
Total  time  to  complete  the  above  steps  is  90-365  calendar  days. 

ASU  Lead  Responsibilities  Time 


1 .  Receive  the  PR  T* 


2. 

Prepare  a  synopsis  and  submit  to 

Commerce  Business  Daily 

T 

15 

days 

3. 

Draft  request  for  proposal  and 
obtain  comments  from  the  SEB 

T 

+ 

75 

days 

4. 

Release  RFP  after  SEB  approval 

T 

+ 

80 

days 

5. 

Receive  technical  proposals 

T 

170 

days 

6. 

Receive  cost  proposals 

T 

+ 

180 

days 

7. 

Evaluate  proposals,  determine  the 
competitive  range,  and  receive  any 
audits  required 

T 

+ 

260 

days 

8. 

Negotiate  technical  factors  and  cost 

T 

+ 

305 

days 

9. 

Request  and  receive  best  and  final 

offers 

T 

+ 

320 

days 

10. 

Evaluate  best  and  final  offers 

T 

335 

days 

11. 

Prepare  the  SEB  report 

T 

+ 

345 

days 

12. 

Obtain  the  source  selection 
official  decision 

T 

+ 

3  65 

days 

13. 

Award  contract  and  release  via 

Public  Affairs  Office 

T 

+ 

370 

days 

*  ™ 
T 

Days 

is  the  date  a  complete  PR,  with  funding, 
are  calendar  days. 

is  received 

in  ASU 

FIGURE  1.3 
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SAMPLE  PROCUREMENT  LEAD-TIME  SCHEDULE  FOR  MAJOR 
DOLLAR  VALUE  NON-COMPETITIVE  PROCUREMENT 


The  following  steps  and  timeframes  apply  to  procurements  estimated 
to  cost  $50M  or  more,  to  be  awarded  without  full  and  open 
competition,  and  to  exclude  8(a)  procedures.  Historically,  it  has 
taken  ASU  9  to  12  months  after  receiving  a  PR  to  award  a  contract. 

Proaram  Manager  Lead  Responsibilities 

1.  Prepare  draft  specifications  and  obtain  approvals 

2.  Acquire  industry  comments  on  draft  specifications  and  perform 
market  survey 

3.  Prepare  an  NCP,  if  necessary,  and  obtain  approval 

4.  Submit  an  approved  PR  to  ASU 

Total  time  to  complete  the  above  steps  is  90-365  calendar  days. 


ASU  Lead  Responsibilities  Time 


Receive  the  PR 

T 

Prepare  a  synopsis  and  submit  to 

Commerce  Business  Daily 

T 

+ 

15 

days 

Draft  an  EIFP  and  obtain  approval  of 
the  JOTFOC 

T 

+ 

60 

days 

Prepare  a  second  synopsis 

T 

+ 

75 

days 

5. 

Release  the  RFP 

T 

+ 

80 

days 

6. 

Receive  proposals  and  request  audit 

T 

+ 

140 

days 

7. 

Audit  received 

T 

+ 

215 

days 

8. 

Proposals  evaluated 

T 

+ 

245 

days 

9. 

Technical  cost  negotiations  complete 

T 

+ 

290 

days 

10 . 

post-negotiation  approval 

T 

310 

days 

11 . 

Award  contract  and  release  news  via 
Public  Affairs  Office 

T 

+ 

320 

days 

T  is  the  date  a  complete  PR,  with  funding,  is  received  in  ASU. 
Days  are  calendar  days. 


FIGURE  1.4 
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SAMPLE  PROCUREMENT  LEAD-TIME  SCHEDULE  FOR  8(A) 
NEGOTIATED  COMPETITIVE  PROCUREMENT  OVER  $3M 


Proaram  Manager  Lead  Responsibilities 


1.  Prepare  draft  specifications  and  obtain  approvals 

2.  Acquire  industry  comments  on  draft  specifications  and  perform 
market  survey 

3.  Prepare  an  NCP,  if  necessary,  and  obtain  approval 

4.  Submit  an  approved  PR  to  ASU 


Total  time  to  complete  the  above  steps  is  90-365 

calendar 

days . 

ASU 

Lead  Responsibilities 

Time 

Prepare  synopsis/letter  to  SBA 

y-* 

•  + 

7 

days 

SBA  response  to  offering  letter 

T 

+ 

28 

days 

Issue  RFP 

T 

+ 

42 

days 

Receive  technical  proposals 

T 

+ 

84 

days 

Receive  cost  proposals 

T 

+ 

94 

days 

Complete  technical  evaluation 

T 

+ 

112 

days 

Determine  competitive  range  and 
request  audits 

T 

119 

days 

8. 

Send  competitive  range  letter  to  SBA 

T 

+ 

126 

days 

9. 

SBA  determines  eligibility 

T 

+ 

133 

days 

10. 

Receive  audit  reports 

T 

+ 

161 

days 

11 . 

Pre— negotiation  position  approved 

T 

4- 

182 

days 

12  . 

Complete  negotiations,  request  best 
and  final  offers  (BAFOs) 

T 

+ 

210 

days 

13. 

Receive  BAFOs 

T 

+ 

224 

days 

14  . 

Award  approval 

T 

+ 

252 

days 

15. 

Award  contract 

T 

+ 

273 

days 

T  is  the  date  a  complete  PR,  with  funding,  is  received  in  ASU. 
Days  are  calendar  days . 


FIGURE  1.5 


SAMPLE  PROCUREMENT  LEAD-TIME  SCHEDULE  FOR  8  (A) 
NEGOTIATED  NON-COMPETITIVE  PROCUREMENT 


Program  Manaaer  Lead  Responsibilities 

1.  Prepare  draft  speeifieations  and  obtain  approvals 

2.  Aequire  industry  eomments  on  draft  speeifieations  and  perform 
market  survey 

3.  Prepare  an  NCP,  if  neeessary,  and  obtain  approval 

4.  Submit  an  approved  IR  t  o  ASLJ 


Total  time  to  eomplete  the  above  steps  is  90- 

ASU  Lead  Responsibilities 

-365  ealendar 

Time 

day  s . 

1. 

Prepare  synopsis  and  offering  letter 
for  SBA 

"P  + 

7 

days 

2. 

SEA  response  to  offering  letter 

T  + 

28 

days 

3. 

Issue  RFP 

T  + 

35 

days 

4. 

Reeeive  proposal  and  request  audit 

T  + 

63 

days 

5. 

Complete  teehnieal  evaluation 

T  + 

91 

days 

6. 

Reeeive  audit  report 

T  + 

105 

days 

7. 

Pre- negotiation  position  approved 

T  + 

112 

days 

8. 

Complete  negotiations 

T  + 

133 

days 

9. 

Award  approval 

T  + 

154 

days 

10. 

Award  eontraet 

T  + 

175 

days 

*  T 
Days 

is  the  date  a  eomplete  PR,  with  funding, 

;  are  ealendar  days. 

is  reeeived  i 

n  ASU. 

FIGURE  1.6 
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Chapter  2 


System  Engineering  And 
Requirements  Process 


This  chapter  discusses  FAA's  system  engineering  process  applied 
during  the  system  life-cycle,  its  input  and  output,  and  the 
associated  requirements  determination  process. 

FAA's  system  engineering  process  encompasses  all  those  technical 
and  management  activities  that  must  be  accomplished  to  produce 
and  deliver  to  the  field  a  system  that  satisfies  the  operational 
need  and  is  affordable,  reliable  and  supportable.  It  also 
encompasses  the  activities  in  the  operations  and  maintenance 
phase  of  the  system  life-cycle  associated  with  the  assessment  of 
system  performance  and  deficiency  correction.  This  system 
engineering  process  requires  the  active,  mutually  supporting, 
participation  of  FAA  operational  elements,  system  engineering 
organizations  and  system  acquisition  offices. 

System  engineering  is  an  iterative  problem  solving  process, 
starting  with  input  (problem  description)  and  ending  with  output 
(system  description  representing  a  problem  solution) .  This  is  an 
information-driven  process  since  descriptions  are  progressively 
transformed  from  input,  at  each  intervening  step,  to  output  at 
succeedingly  greater  levels  of  detail. 

FAA's  system  engineering  process  is  applied  during  each  phase  of 
the  system's  life— cycle.  The  process  is  used  to  identify  and 
define  operational  mission  needs,  transform  the  operational  needs 
into  system  performance  parameters  and  a  system  description,  and 
to  identify,  define,  and  allocate  the  functional  characteristics 
for  each  NAS  subsystem.  The  functions  are  allocated  to  equipment 
(hardware  and  software),  facilities,  procedures,  and  personnel. 

A  generic  system  engineering  process  consists  of  the  following 
major  elements: 

o  Requirements  analysis 

o  Functional  analysis/allocation 

o  Synthesis 

o  System  analysis 


Requirements  analysis  is  initially  concerned  with  deriving 
technical  performance  requirements  from  approved  statements  of 
mission  need.  In  subsequent  acquisition  phases,  requirements 
analysis  is  applied  iteratively  to  provide  progressively  more 
detailed  technical  performance  requirements  definition. 

Functional  analysis/allocation  identifies  the  functions  that  must 
be  performed,  defines  functional  performance  requirements  and 
allocates  these  functions  to  different  system  elements. 

Synthesis  is  initially  concerned  with  preliminary  system  concept 
descriptions  or  alternatives  that  may  contain  different 
functional  allocations.  Functional  analysis  results  are  used 
during  the  synthesis  step  of  the  system  engineering  process. 
Synthesis  provides  the  basis  for  determining  to  which  NAS 
subsystem  required  functions  should  be  allocated. 

System  analyses  is  applied  concurrently  with  the  other  activities 
to  assess  alternatives  in  meeting  system  requirements.  During 
system  analysis  there  is  an  examination  of  key  factors  in  a 
quantitative  manner  for  selection  of  a  cost-effective  solution. 
The  selected  solution  is  then  documented  in  a  specification 
format.  At  the  NAS  level,  the  system  description  documentation 
is  comprised  of  the  NAS  Level  I  Design  Document  (NAS-DD-1 000)  and 
NAS  System  Specification  (NAS— SS— 1000) .  Figure  2.1  shows  the 
relationship  of  the  major  system  engineering  process  functions. 

Process  Description 

To  better  understand  the  FAA  system  engineering  process,  the 
following  topics  will  be  presented: 

o  System  engineering  and  the  acquisition  process 

o  Requirements  determination 

o  Mission  need  analysis 

o  Mission  need  statement 

o  System  requirements 

o  Requirements  traceability 

o  Requirements  changes 

o  NAS  system  description  documentation 

o  System  engineering  management 


System  Engineering  and  the  Acquisition  Process 


The  continuing  growth  and  diversity  in  aircraft  operations  and 
increasing  sophistication  of  aircraft  and  avionics  are  placing 
unprecedented  demands  on  the  National  Airspace  System  (NAS)  of 
the  future.  In  response  to  this,  the  NAS  is  evolving  into  a  very 
complex  and  highly  interdependent  system.  The  design  and 
acquisition  of  the  evolving  NAS  systems  is  a  major  engineering 
undertaking,  and  requires  a  sustained  and  comprehensive  FAA-wide 
system  engineering  process  for  supporting  the  FAA  system 
acquisition  life— cycle. 

The  FAA  system  acquisition  life-cycle  is  based  on  the  Office  of 
Management  and  Budget  (OMB)  Circular  A— 109  which  established  a 
structured  process  for  major  system  acquisitions  in  the  federal 
government.  Within  FAA,  the  A— 109  acquisition  concept  is  applied 
to  both  major  and  non-major  system  acquisitions. 

The  major  system  engineering  objectives  of  the  various  phases  of 
the  FAA  system  acquisition  life-cycle  along  with  the  associated 
requirements  determination  process  are  shown  in  Figure  2,2. 

System  engineering  activities  supporting  these  objectives  require 
full  participation  of  and  contributions  from  various 
organizations  throughout  the  agency. 

Requirements  Determination 

The  phrase  Requirements  Determination  as  defined  herein  refers  to 
a  set  of  activities  that  precedes  the  preparation  of  a  formal 
specification  for  a  NAS  subsystem.  Requirements  Determination  is 
evolutionary  and  consists  of  a  set  of  generic  activities  that 
occur  in  one  form  or  another  during  each  phase  of  the  process. 

Within  the  framework  of  FAA's  acquisition  process,  the  first 
occurrence  of  Requirements  Determination  begins  prior  to  Key 
Decision  Point  #1  (KDP-1)  with  a  description  of  mission  need  in 
the  form  of  a  mission  need  statement  and  spans  across  KDP-1  into 
Phase  1  where  a  Type  A  system  level  specification  is  developed. 

As  the  program  matures  and  passes  through  succeeding  phases  of 
FAA's  acquisition  process,  other  Requirements  Determination  takes 
place  resulting,  in  order  of  occurrence:  a  type  B  development 
specification,  and  a  type  C  production  specification  as  well  as 
other  related  specifications,  such  as  type  D  and  type  E. 

During  Phase  0  the  Requirements  Determination  takes  place  in  the 
form  of  describing  a  shortfall  in  mission  capability  and 
expressing  this  in  a  format  of  a  mission  need  statement.  During 
the  development  of  a  mission  need  statement,  a  mission  need 
analysis  activity  assists  in  identifying  and  analyzing  relevant 
data  that  clarifies  and  explains  the  mission  need  in  terms  needed 
to  support  the  FAA'’ s  Acquisition  Review  Committee  (ARC)  KDP— 1 
decision  process. 


Mission  Need  Analysis 

A.  Background 

As  recently  introduced  within  FAA,  MNA  is  the  initial  activity  of 
the  formal  acquisition  process.  This  initial  phase  relies 
heavily  on  analysis  to  define  a  problem  of  mission  capability 
shortfall.  In  this  sense,  mission  capability  refers  to  those 
functions  that  must  be  performed  for  FAA  to  provide  the  services 
dictated  by  statute.  The  objective  of  MNA  is  to  support  the 
development  of  sound  mission  need  statements  <MNSs) .  An  MNS  is  a 
convenient  form  for  summarizing  specified  items  of  information  to 
facilitate  review  and  approval  by  senior  FAA  managers . 

As  the  initial  phase  of  the  system  acquisition  process,  MNA 
involves  defining  a  problem,  while  the  remainder  of  the  phases 
relate  to  the  development  of  a  cost-effective  solution,  and  its 
production/deployment,  operation  and  support.  The  MNA  activity 
ends  when  a  mission  need  statement  has  been  reviewed  and  approved 
by  the  appropriate  FAA  acquisition  executive  which  constitutes 
receiving  key  decision  point-1  (KDP-1)  approval.  The  basic  idea 
for  MNA  is  that  the  justification  for  acquisition  decisions  can 
be  vastly  improved  through  more  effective  efforts  to  identify, 
describe,  and  explain  mission  capability  shortfalls  as  one  major 
prerequisite  to  initiating  a  new  acquisition  program. 

In  view  of  the  rapid  pace  with  which  technology  advances, 
providing  an  increasingly  varied  array  of  software,  hardware,  and 
system  choices,  it  is  essential  to  understand  mission  needs 
stated  in  terms  of  functional  capabilities  rather  than  in  terms 
of  specific  equipment  or  technology.  When  it  is  realized  that 
systems  acquired  today  may  have  lifetimes  of  20  or  more  years,  it 
is  clear  that  with  present  rates  of  change,  technology  will 
advance  through  ten  or  more  cycles  of  development  during  this 
period.  In  this  environment,  specifying  particular  equipment 
configurations  as  solutions  to  operational  needs  quickly  becomes 
an  exercise  in  dealing  with  obsolete  technology. 

Approval  and  funding  for  new  FAA  programs  has  become  increasingly 
difficult  to  justify  using  criteria  that  only  a  few  years  ago 
were  considered  to  be  sufficient.  Over  the  years,  FAA's  budgets 
have  consistently  increased  as  efforts  to  modernize  the  National 
Airspace  System  (NAS)  infrastructure  have  progressed  and  this  has 
tended  to  increase  the  amount  of  oversight  received.  More 
recently,  oversight  agencies  and  Congressional  committees  have 
been  imposing  more  stringent  demands  on  FAA  to  demonstrate  that 
quantitative  analysis  is  being  to  support  acquisition  decisions. 

Thus,  it  is  essential  that  FAA  improves  its  methodology  for 
defining  mission  needs  with  the  expectation  that  this  will  lead 
to  improved  definition  of  post  KDP-1  system  requirements.  This 
includes  improving  the  methodology  to  translate  mission  needs 


into  formal  specifications  for  use  in  identifying  a  range  of 
feasible  conceptual  system  designs  from  which  to  select  the  most 
cost-effective  choice,  during  the  post  KDP-1  phases  of  a  system 
acquisition  program. 

The  balance  of  this  section  describes  MNA  as  it  is  conceptualized 
and  being  implemented  throughout  the  agency. 

B.  Mission  Need  Analysis  Process 

For  the  purpose  of  this  Guide,  it  is  convenient  to  regard  KDP— 1 
as  partitioning  the  life— cycle  of  a  generic  system  into  two 
contiguous  domains.  In  Figure  2.3,  the  first  of  these  domains  is 
referred  to  as  Problem  Definition  which  is  shown  to  the  left  of 
KDP-1.  The  second  domain  is  referred  to  as  Problem  Solution  and 
is  shown  to  the  right  of  KDP-1. 

The  post-KDP-1  phases  of  the  acquisition  process  are  the  ones 
that  are  most  familiar  to  the  majority  of  hardware  and  software 
system  engineering  in  FAA.  On  the  other  hand,  the  pre-KDP-1 
phase  is  the  least  familiar,  even  though  it  is  both  a  legitimate 
and  logical  part  of  a  system  acquisition  process.  During  the 
concept  exploration  phase  of  a  particular  system  acquisition 
program,  a  system  level  specification  (Type  A)  is  developed  which 
defines  the  system  requirements  that  eventually  are  translated 
into  a  range  of  system  design  concepts  and  ultimately  into  the 
preferred  operational  system  by  various  kinds  of  system  engineers 
and  technical  managers. 

During  MNA,  however,  there  is  no  system-level  specification; 
instead,  there  is  only  mission  needs  determination.  What  is 
sought  is  a  clear  understanding  of  the  shortfall  in  mission 
capability  and  a  way  to  develop  a  valid  representation  of  the 
entailed  functional  deficiency,  both  in  symbolic  and  narrative 
form.  An  important  aspect  of  MNA  is  to  determine  the  degree  of 
operational  urgency  involved  in  satisfying  a  mission  need. 

Not  all  mission  needs  are  necessarily  satisfied  by  a  formal 
acquisition  process,  including  the  kind  of  review  and  approval 
decision  processes  as  might  be  involved  in  the  case  of  a  major 
system  acquisition.  In  fact,  FAA  Order  1810. IF  requires  that  all 
feasible  low— capital  intensive  investments  be  identified  and 
evaluated  as  possible  ways  of  satisfying  a  given  mission  need  as 
a  precondition  to  initiating  a  new  system  acquisition  program. 
Within  FAA  these  low-capital  intensive  investment  possibilities 
are  referred  to  as  non-materiel  solution  approaches  and  the 
assessment  of  these  takes  place  during  MNA. 

Thus,  MNA  is  a  process  to  develop  a  problem  statement  and  to 
determine  if  satisfaction  of  that  need  can  be  achieved  by  low 
cost  approaches  such  as  changes  in  procedures  or  policy, 
reallocation  of  existing  assets,  or  improved  training  before 


development  of  a  mission  need  statement.  Only  for  the  case  where 
MNA  has  established  that  these  low  cost  solution  approaches  are 
infeasible  does  it  become  possible  to  consider  a  new  system 
acquisition  program.  In  the  latter  case,  MNA  is  often  thought  of 
only  as  providing  the  justification  for  initiating  a  new  system 
acquisition  program;  however,  as  conceptualized,  it  is  intended 
to  identify  and  satisfy  mission  needs.  In  other  words,  the 
objective  of  MNA  could  be  expressed  as  assuring  that  FAA  acquires 
the  requisite  capabilities  to  provide  mission  services. 

Identification  and  evaluation  of  low-cost  alternative  approaches 
are  associated  with  MNA  so  that  these  possibilities  may  be 
considered  during  pre-KDP-1 .  On  the  other  hand,  development  and 
assessment  of  alternative  system  design  concepts  are  associated 
with  Phase  1  Concept  Exploration/Alternative  Analysis.  Often 
these  two  sets  of  related,  but  distinct  descriptors  become 
confused,  resulting  in  identification  of  feasible  or  even 
preferred  solutions  being  attempted  prematurely  during  MNA.  This 
results  in  mission  need  statements  that  are  prepared  where  a 
preferred  solution  has  already  been  identified  at  the  expense  of 
a  poorly  described  mission  need.  This  amounts  to  a  high-risk 
approach  to  initiate  a  new  system  acquisition  program. 

Figure  2.4  is  a  functional  flow  block  diagram  which  shows  the 
relationship  of  the  MNA  process  to  the  remainder  of  a  generic 
system  life-cycle  process.  As  shown  in  the  figure,  modules  3.0 
and  4.0  correspond  to  the  remaining  portions  of  FAA^ s  system 
life— cycle.  However,  as  shown  along  the  bottom  of  the  figure 
there  is  a  feedback  loop  that  connects  module  4.0  and  module  2.0. 
This  loop  is  regarded  to  be  a  significant  structural  feature  of 
the  MNA  process  that  provides  data  and  information  on  the  state 
and  condition  of  the  NAS.  This  information  will  be  needed  during 
MNA  in  developing  a  mission  capability  supply  function. 

Module  1.0  involves  a  variety  of  major  factors,  other  than 
strictly  mission  need,  that  could  influence  the  outcome  of  MNA. 
For  example,  such  factors  include  demands  for  service,  national 
policies,  either  as  Congressional  guidance  or  as  described  in 
existing  or  new  statutes,  or  the  possibilities  for  new  options 
for  satisfying  mission  needs  resulting  from  technology 
assessment . 

As  shown  in  Figure  2.5a,  the  basic  idea  underlying  FAA's  concept 
of  a  mission  need  determination  process  has  three  components. 

The  first  component  of  the  MNA  process  involves  projections  of 
services  that  FAA  will  have  to  provide  in  satisfying  its  mission 
responsibilities  now  and  in  the  future.  Consistent  with  a 
planning  horizon  of  10  to  12  years,  it  is  possible  to  develop  an 
approximate  estimate  of  FAA  capabilities  needed  to  provide 
projected  mission  services  as  required  by  statutory  language. 

This  projection  of  needed  mission  capabilities  is  best  thought  of 


as  a  demand  function  of  time  and  is  shown  as  a  curve  which 
increases  with  time  to  indicate  anticipated  growth. 


As  shown  in  Figure  2.5b,  the  second  component  of  the  MNA  process 
involves  projections  for  services  that  FAA  will  be  able  to 
provide  with  planned  use  of  existing  facilities  and  equipment  now 
and  in  the  future.  Consistent  with  this  planning,  it  is  possible 
to  develop  an  appropriate  estimate  of  FAA  capabilities  that  will 
be  available  from  systems  presently  in  operation  and  those  that 
are  expected  to  come  on  line  during  the  planning  period.  This 
projection  of  available  mission  capabilities  is  best  thought  of 
as  a  supply  function  of  time  and  is  shown  as  a  curve  that 
decreases  with  time  to  indicate  wear  and  tear  and  technological 
obsolescence . 

As  shown  in  Figure  2.5c,  the  third  component  of  the  MNA  process 
involves  comparing  the  capability  demand  function  with  the 
capability  supply  function,  and  from  developing  a  capability 
shortfall  function  over  the  span  of  the  planning  horizon.  When 
such  a  shortfall  is  identified,  it  is  associated  with  needed 
mission  services  and  this  information  provides  the  substantive 
content  of  a  mission  need  statement. 

The  definition  of  specific  system  acquisitions  whether  funded  by 
the  research,  engineering  &  development  (R,E&D)  appropriation,  or 
by  the  facilities  and  equipment  (F&E)  appropriation  or  the 
Operations  appropriation  should  be  based  on  reduction  of  a 
specific  increment  of  the  projected  mission  capability  shortfall, 
within  some  specified  interval  of  time. 

FAA  has  established  a  mission  needs  analysis  team  (MNAT) ,  lead  by 
AOR— 100,  to  support  FAA  sponsor  organizations  by  conducting 
mission  needs  analysis  for  each  sponsor's  organization  mission 
area. 

C.  Operational  Need  Description 

This  section  discusses  the  principle  elements  that  would  provide 
a  clear,  unambiguous,  and  complete  description  of  the  operational 
capabilities  needed  to  perform  an  assigned  FAA  mission.  This 
description  should  include  the  following  elements: 

Operational  Environment 
Operational  Constraints 
Operational  Concept 
Measures  of  Effectiveness 

-  Performance  Attributes  &  Performance  Characteristics 
Time  Urgency  of  Mission  Need 


The  following  is  a  definition  of  these  elements: 

_  Operational  Environment  “  Description  of  those 

conditions  that  any  system  concept  whose  purpose  is  to 
satisfy  the  mission  need  would  observe  during 
operational  use 

_  Operational  Constraints  -  Description  of  sets  of 

criteria  that  must  be  satisfied  by  any  system  concept 
whose  purpose  is  to  satisfy  the  mission  need.  In 
particular,  these  sets  of  criteria  relate  to  conditions 
of  infrastructure  support  that  may  impact  on 
satisfaction  of  the  mission  need. 

_  Operational  Concept  -  Description  of  how  the 

functionality  will  be  used  in  the  NAS  under  operating 
conditions 

_  Measures  of  Effectiveness  -  Description  of  those 

"yardsticks"  of  performance  that  serve  to  indicate  the 
degree  to  which  proposed  solutions  are  able  to  satisfy 
an  identified  mission  need 

For  complex  systems  it  is  possible  to  identify  many 
indicators  associated  with  the  functioning  of  the 
system.  However,  not  all  of  these  indicators  are 
useful  for  purposes  of  evaluating  the  effectiveness  of 
alternative  system  concepts  in  satisfying  mission 
needs . 

In  many  cases  the  appropriate  Measures  of  Effectiveness 
are  constructed  from  various  subsets  of  indicators, 
that  when  taken  individually  are  not  very  informative 
about  the  mission  effectiveness  of  the  system  under 
consideration . 

_  Performance  Attributes  &  Performance  Characteristics  - 

Identification  of  those  performance  parameters  which 
are  useful  in  quantifying  needed  mission  capabilities. 
Performance  characteristics  are  the  desired  range  of 
numerical  values  that  the  performance  attributes  may 
take  on. 

_  Time  Urgency  of  Mission  Need  -  Description  of  the  time- 
frame  within  which  the  capability  shortfall  must  be 
resolved  in  order  for  FAA  to  accomplish  its  mission 
objectives 


Mission  Need  Statement 


A  mission  need  statement  (MNS)  is  intended  to  be  a  summary 
document  that  contains  a  distillation  of  comprehensive  analysis 
that  has  been  done  to  best  represent  a  sponsor's  authenticated 
mission  need. 

A  MNS  is  required  to  initiate  all  system  acquisition  programs 
regardless  of  appropriation.  The  initial  MNS  summarizes  the 
results  of  the  mission  need  analysis.  Approval  of  the  MNS 
constitutes  achievement  of  the  KDP— 1  milestone.  The  mission 
needs  analysis  team,  led  by  the  Operations  Research  Service  and 
supported  by  System  Engineering  organizations,  supports  the 
sponsoring  FAA  operating  element  having  the  mission  need. 

Subsequent  updated  mission  need  statements  to  support  KDP— 2 
through  KDP-4  decisions  are  prepared  by  the  sponsors  and  program 
manager,  reviewed  by  the  mission  need  analysis  team  and  System 
Engineering  organizations,  and  approved  by  appropriate  management 
levels  to  reaffirm  the  need  and  the  associated  requirements. 

System  Requirements 

When  a  mission  need  statement  is  approved  at  KDP-1  the 
Requirements  Determination  process  continues  with  the  formulation 
of  technical  system  requirements  necessary  to  support  the 
development  of  a  formal  specification  for  a  NAS  subsystem. 

The  initial  activity  of  Requirements  Determination  during  Phase  1 
of  the  acquisition  process  is  to  translate  the  approved  mission 
need  statement  into  a  preliminary  set  of  technical  requirements. 
The  result  of  this  effort  serves  as  the  substantive  content  of  an 
associated  Operational  Requirements  Document  (ORD) . 

The  purpose  of  the  Operational  Requirements  Document  is  to 
document  a  preliminary  set  of  performance  and  supportability 
requirements  for  a  subsystem  of  the  NAS.  In  developing  the  ORD 
for  a  subsystem  of  the  NAS,  the  operational  requirements  for  the 
NAS  as  a  whole,  contained  in  NAS-SR-1000,  needs  to  be  taken  into 
account.  The  Operational  Requirements  Document  will  be  used  as  a 
basis  for  developing  a  system  level  specification,  otherwise 
known  as  an  A-Type  specification.  In  addition  to  the 
requirements  contained  in  the  ORD,  the  A-Type  specification  will 
contain  other  requirements  developed  by  the  NAS  System 
Engineering  Organizations  such  as  Interface  Requirements 
Document (s).  Facility  Requirements,  Verification  Requirements, 
and  other  requirements  imposed  by  FAA  Standards  or  Orders. 

This  total  set  of  requirements  essentially  sets  the  stage  for  a 
large  fraction  of  the  activity  that  follows  as  the  acquisition 
process  continues. 


An  associated  activity  of  the  post  KDP-1  technical  requirements 
formulation  process  is  alternative  analysis.  The  purpose  of  this 
activity  is  to  assure  that  a  number  of  appropriate  technologies 
have  been  identified  for  examination  during  Phase  1  of  the 
acquisition  process.  This  includes  assuring  that  a  number  of 
system  design  concepts  are  developed  for  each  of  the  appropriate 
technologies  in  an  effort  to  identify,  in  a  preliminary  manner, 
the  most  cost-effective  of  the  solution  alternatives. 

In  subsequent  phases  of  the  acquisition  process,  the  system  level 
requirements  are  transformed  into  a  greater  level  of  detail 
through  iterations  of  the  system  engineering  process  functions  of 
requirements  analysis,  functional  analysis/allocation,  synthesis, 
and  system  analysis.  The  output  of  each  system  engineering 
process  iteration  serves  as  input  to  the  next  iteration.  Each 
application  of  the  system  engineering  process  at  succeeding  steps 
results  in  more  detailed  NAS  element  descriptions  until 
product ion— ready  documentation  of  all  subsystem  elements  is 
reached  and  the  subsystem  is  produced. 

During  the  translation  of  system— level  requirements  to  greater 
levels  of  detail,  system  analysis  should  be  applied  continuously 
and  in  parallel  with  the  other  activities  of  the  system 
engineering  process.  This  function  focuses  on  assuring  that 
system  effectiveness,  design-to— cost,  and  life-cycle  cost 
objectives  as  well  as  other  factors  are  taken  into  account  in 
assessing  design  alternatives. 

The  preliminary  set  of  operational  performance  and  supportability 
requirements  documented  in  the  initial  Operational  Requirements 
Document  are  refined  in  system  acquisition  phases  2  and  3  as  a 
result  of  assessing  any  conflicts  that  may  exist  among  system 
requirements,  cost— factors,  risk  factors,  system  effectiveness, 
support  effectiveness,  testing  effectiveness,  and  operational 
effectiveness.  In  other  words,  the  operational  performance  and 
supportability  requirements  contained  in  the  initial  Operational 
Requirements  Document  should  not  be  considered  "absolute"  in  the 
sense  that  they  should  be  achieved  at  any  cost. 

At  the  point  in  the  acquisition  process  where  the  preferred 
system  solution  is  selected,  usually  in  phase  2  or  3  of  the 
acquisition  process,  the  NAS  baseline  documents,  NAS-DD-1000  and 
NAS— SS— 1000,  are  updated  via  a  NAS  Change  Proposal. 

Requirements  Traceability 

The  performance  and  supportability  requirements  contained  in  the 
Operational  Requirements  Document  should  be  traceable  to  the 
mission  need  statement  and  NAS-SR-1000.  Other  requirements 
contained  in  the  A-Type  specification  should  be  traceable  to  NAS 
baseline  documentation  such  as  Interface  Requirements  Documents, 
FAA  engineering  standards,  applicable  FAA  Orders  and  other  NAS 
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baseline  documentation.  Subsequent  detailed  specifications  (Type 
B,  C,  etc.)  should  be  traceable  back  to  the  System  level 
specification  (Type  A)  and  NAS  baseline  documentation. 

Requirements  Changes 

Proposed  changes  to  Operational  Requirements  Documents  are 
approved  at  Key  Decision  Milestones  2  and  3.  The  proposed 
changes  are  reviewed  by  NAS  System  Engineering  organizations  to 
assess  the  impacts  of  the  proposed  requirements  changes  on  the 
performance  of  the  NAS  as  a  whole.  The  ORDs  are  approved  by 
the  FAA  operational  elements,  usually  Air  Traffic,  Flight 
Standards  and  Airway  Facilities. 

NAS-SR-1000,  NAS-DD-1000,  and  NAS-SS-1000  are  updated  as  new 
capabilities  are  identified  and  developed,  and  existing  systems 
are  retired.  Changes  to  these  baseline  documents  are  processed 
through  the  NAS  Configuration  Management  System,  Crder  1800. 8F, 
which  draws  on  the  expertise  of  various  FAA  organizations  to 
review  proposed  changes.  The  process  is  initiated  when  a  sponsor 
prepares  and  submits  a' NAS  Change  Proposal  (NCP) ,  The  NAS 
Configuration  Control  Board  (NAS  CCB)  controls  NAS— SR— 1000,  NAS- 
DD-1000,  and  NAS-SS-1000.  When  an  NCP  is  approved,  the  change 
becomes  part  of  the  baseline  documentation. 

NAS  System  Description  Documentation 

The  NAS  system  description  is  documented  in  NAS-DD-1000  and 
NAS— SS— 1000.  These  documents  define  the  NAS  system— level 
functional,  performance,  interface  and  verification  requirements 
that  respond  to  the  overall  NAS  operational  performance  and 
supportability  requirements  described  in  NAS— SR— 1000.  As 
preferred  system  solutions  are  selected  during  the  acquisition 
process,  NAS-DD-1000  and  NAS-SS-1000  are  updated. 

NAS-DD-1000  presents  a  qualitative,  high-level  system  definition 
which  identifies  the  allocation  of  functions  to  specific 
subsystems  and  elements,  provides  a  description  of  the  functional 
interfaces,  and  outlines  the  data  flow  across  each  interface. 

NAS— SS— 1000  is  organized  into  the  following  six  volumes: 

o  Volume  I:  General.  This  volume  contains  those 

requirements  that  are  applicable  across  the  entire  NAS 
or  are  common  to  two  or  more  subsystems.  Appendix  i 
contains  the  system-level  performance  requirements.  It 
also  contains  the  verification  requirements 
traceability  matrices  (VRTM)  which  are  intended  for  use 
in  Test  and  Evaluation  Master  Plans  (TEMPs) .  Appendix 
11/  the  NAS  Architecture,  is  a  separately  bound 
document  which  contains  the  quantity  and  location  of 


subsystems  and  facilities.  Appendix  III  is  the  NAS 
Maintenance  Support  Requirements. 

o  Volume  II:  Air  Traffic  Control  Element.  This  volume 
is  an  extension  of  the  applicable  requirements 
contained  in  Volume  I  for  the  air  traffic  control  (ATC) 
element.  It  specifically  defines  requirements  at  the 
subsystem  level  for  ATC,  flight  planning,  traffic 
management,  and  weather  processing  functions. 

o  Volume  III:  Ground-to-Air  Element.  This  volume  is  an 

extension  of  the  applicable  requirements  contained  in 
Volume  I  for  the  ground— to— air  element.  It 
specifically  defines  requirements  at  the  subsystem 
level  for  weather  sensing,  navigation,  landing, 
surveillance,  and  remote  communications  functions. 

o  Volume  IV:  Communications  Element.  This  volume  is  an 

extension  of  the  applicable  requirements  contained  in 
Volume  I  for  the  communications  element.  It 
specifically  defines  requirements  at  the  subsystem 
level  for  control,  voice  switching,  data  switching,  and 
transmission  functions. 

o  Volume  V:  Maintenance  and  Operations  Support  Element. 
This  volume  is  an  extension  of  the  applicable 
requirements  contained  in  Volume  I  for  this  element. 

It  specifically  defines  requirements  at  the  subsystem 
level  for  remote  maintenance  monitoring  system  and 
system  support  facility  functions. 

o  Volume  VI:  Facility  Requirements.  This  volume 
currently  contains  the  facility  requirements  and 
subsystem  environmental  requirements  for  the  Area 
Control  Facility  (ACF)  and  Airport  Traffic  Control 
Tower  (ATCT) .  Future  updates  will  identify 
requirements  for  the  Automated  Flight  Service  Station 
(AFSS) ,  remote  and  unmanned  facilities,  Metroplex 
Control  Facility  (MCF) ,  Local  Control  Facility  (LCF) 
and  facilities  related  to  National  Traffic  Flow 
Management . 

System  Engineering  Management 

The  NAS  System  Engineering  Service  (ASE)  and  the  Facility  System 
Engineering  Service  (AFE)  have  established  System  Managers  and 
Associate  Program  Managers  for  System  Engineering  (APMSE)  to 
support  FAA  system  acquisitions.  This  section  describes  the  role 
of  the  System  Manager  and  the  APMSE. 


A.  System  Manager 


System  Managers  are  appointed  to  coordinate  oversight  and 
planning  for  selected  operational  domains  and  technical 
initiatives  that  involve  the  work  of  many  organizations  and 
interests  within  the  FAA,  and  the  national  and  international  user 
and  supplier  communities. 

The  System  Manager  functions  as  the  leader  and  spokesperson  for 
the  assigned  operational  domain  or  technical  initiative  within 
FAA,  and  on  behalf  of  the  United  States  in  international  forums. 
She/he  functions  as  a  coordinator  of  diverse  planning, 
development,  and  implementation  activities  within  the  overall 
aviation  community,  and  serves  to  organize  special  activities 
needed  to  resolve  issues  within  this  constituency.  The  System 
Manager  serves  as  a  long-range  planner  and  system  "integrator" 
across  the  range  of  activities  throughout  the  domain/initiative 
life  cycle. 

The  System  Manager  is  expected  to  have  a  broad  "system 
perspective",  and  influence  policy  development  within  her/his 
assigned  operational  domain  or  technical  initiative.  The  System 
Manager  does  not  have  direct  funding  authority,  nor  does  she/he 
manage  acquisition  programs.  The  System  Manager  is  expected  to 
act  as  an  integrative  force,  and  does  not  normally  take 
adversarial  positions. 

The  System  Manager  organization  consists  of  the  designated  System 
Manager,  a  Deputy,  and  a  small  staff  of  experts.  The  System 
Manager  organizes  additional  operational  and  engineering  teams 
composed  of  members  of  the  key  FAA  organizations  having  mission 
responsibilities  in  the  assigned  operational  domain/initiative. 

It  is  these  teams  that  accomplish  the  bulk  of  the  product  for 
which  the  System  Manager  is  held  responsible. 

System  Manager  products  include  a  Vision  Paper,  an  Operational 
Concept,  a  System  Plan  (outlining  the  evolution  of  the 
domain/initiative) ,  and  guidance  letters  to  the  responsible 
organizations . 

The  following  is  a  brief  description  of  each  System  Manager's 
area  and  points  of  contact: 

1.  Oceanic  System  Manager,  ASE-6 

The  oceanic  domain  consists  of: 

o  All  oceanic  and  off-shore  airspace  where  New  York, 
Oakland,  and  Anchorage  Air  Route  Traffic  Control 
Centers  currently  serve  as  the  oceanic  control 
facilities,  and  Houston  and  Honolulu  currently  provide 
off-shore  control  services 


o 


All  functional  areas  of  the  system  such  as  automation, 
communications,  navigation,  surveillance,  airspace, 
procedures,  and  people  and  all  phases  of  the  system 
life  cycle 

The  FAA's  oceanic  domain  is  a  multifaceted  activity  that 
includes  automation  systems  for  Air  Traffic  Control  and  traffic 
flow  management,  air/ground  voice  and  data  communications, 
interfacility  voice  and  data  communications,  dependent 
surveillance  systems,  navigation  system,  airspace,  procedures 
and  people.  There  is  a  significant  need  to  integrate  and 
coordinate  these  pieces  of  the  system  to  realize  tangible 
benefits  to  the  airspace  user  and  controller  by  the  mid-1990's, 
and  to  provide  an  evolutionary  path  to  the  future.  The  Oceanic 
System  Manager  has  the  mission  of  defining  and  facilitating  the 
evolution  of  the  oceanic  system  so  that  user  and  operator  needs 
are  expeditiously  met. 

Points  of  contact  for  the  oceanic  domain  are: 

System  Manager  -  Joseph  Fee,  ASE-6,  202-287-8608 
Deputy  System  Manager  -  Ved  Sud,  ASE— 6.1,  202—287—8609 
2.  Data  Link  System  Manager,  ASE— 7 

The  Aeronautical  Data  Link  System  (ADL5)  domain  encompasses  all 
elements  required  to  fully  integrate  data  communications  into 
operations  throughout  the  National  Airspace  System.  These 
elements  consist  of:  Air  Traffic  Control  and  Elight  Information 
Service  applications;  data  link  services  and  communications 
integrated  into  existing  and  evolving  ground  automation  systems; 
the  air/ground  and  supporting  ground/ground  data  communications 
architecture  and  infrastructure;  airborne  avionics  systems; 
policies  and  procedures  that  enable  user  benefits  through  data 
communications.  When  these  elements  are  integrated  as  a  system, 
substantial  safety,  operational  and  economic  benefits  can  be 
provided  to  the  user  community,  consisting  of  aircraft  operators 
and  airspace  managers .  There  is  a  growing  drive  from  the 
aviation  industry  to  implement  the  ADLS  in  a  timely  manner  to 
achieve  user  benefits.  To  ensure  this  need  is  met  by  the  FAA, 
the  Data  Link  System  Manager: 

o  Coordinates  across  organizational  elements  and  with  the 
external  user  community  to  develop  an  ADLS  vision, 
operational  concept,  operational  requirements,  and 
system  plan 

o  Coordinates  priorities,  schedules,  plans  and  budgets  to 
ensure  that  all  necessary  elements  are  aligned  and  will 
be  available  when  required 
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o 


Serves  as  the  FAA  focal  point  for  coordinating  ADLS 
plans  and  policies  within  the  FAA,  and  with  external 
organizations  and  other  civil  aviation  authorities 


Points  of  contact  for  the  Data  Link  system  domain  are: 

System  Manager  -  Hugh  McLaurin,  ASE-7,  202—287—8783 

Deputy  System  Manager  -  Charlotte  LaQui,  ASE-7, 
202-287-8753 

3.  Satellite  Communication,  Navigation,  and  Surveillance 
System  Manager,  ASE— 8 

The  Satellite  Communications,  Navigation,  and  Surveillance  (CNS) 
System  Manager  plans  and  directs  the  integration  of  the  Satellite 
Program  within  FAA  and  with  external  agencies  to  ensure  the 
conversion  of  operational  requirements  into  effective,  efficient, 
economical,  and  safe  service  in  the  National  Airspace  System. 

The  Satellite  CNS  area  is  comprised  of  all  those  activities 
necessary  to  define,  develop,  produce  and  implement  satellite  CNS 
capabilities  within  NAS. 

Points  of  contact  for  the  Satellite  CNS  area  are: 

-  System  Manager  -  Mike  Shaw,  ASE— 8,  202—287—8754 

Deputy  System  Manager  -  Kan  Sandoo,  ASE— 8, 

202-287-8624 

4.  Traffic  Flow  Management  System  Manager,  ASE-9 

The  Traffic  Flow  Management  Domain  encompasses  all  the 
subsystems  -  personnel,  procedures,  automation  and 
communications  required  for  Air  Traffic  Management  to  perform 
the  strategic  activities  related  to  overall  management  of  air 
traffic.  This  includes  longer  range  planning  (including 
modeling  and  airspace  realignments)  as  well  as  flow  control 
activities  on  the  day  of  flight  activities.  The  Traffic  Flow 
Management  System (s)  must  interface  with  the  NAS  primarily 
through  the  air  traffic  control  automation  subsystem,  both  to 
obtain  flight  plan  and  track  data  and  to  provide  flow 
management  directives  to  air  traffic  control  for 
implementation . 

Points  of  contact  for  the  Traffic  Flow  Management  Domain  are: 

System  Manager  -  Mike  Ball,  ASE-9,  202-287-8575 

Deputy  System  Manager  -  Diane  Boone,  ASE— 9.1, 

202-287-8616 


5.  Weather  System  Manager,  ASE— 10 


The  Weather  System  Manager  directs  the  coordination  and 
integration  of  all  weather  and  weather  support  requirements, 
research,  implementation,  and  activities  within  the  agency  and 
external  to  the  agency  including  the  National  Oceanic  and 
Atmospheric  Administration  (NOAA)  and  domestic/ international 
aviation  weather  user  groups.  Specific  activities  include  long 
range  planning,  top  level  requirements,  weather  system 
architecture  for  support  to  the  NAS,  system  interfaces  and  budget 
prioritization. 

Points  of  contact  for  the  Weather  and  Weather  Support 
Operational  Domain  are: 

System  Manager  -  Carl  McCullough,  ASE— 10,  202—287—8595 

Deputy  System  Manager  -  Carol  Branscome,  ASE— 10.1, 
202-287-7093 

Deputy  System  Manager  -  R.  Craig  Goff,  ASE— 10.2, 
202-287-8642 

6.  Tower  System  Manager,  AEE— 5 

The  Tower  System  Manager  provides  cross  service  coordination  of 
the  Tower  domain,  including  all  aspects  of  system  engineering 
coordination  (including  equipment  and  facilities) .  The  Tower 
System  Manager  chairs  the  Tower  Matrix  Team,  represented  by 
nearly  every  service.  The  matrix  team  addresses  issues  and 
problem  resolution  as  we  evolve  to  the  Tower  of  the  future. 

Points  of  contact  for  the  Tower  Domain  are: 

System  Manager  -  Jim  Lenz,  AFE— 5,  202—287—8593 

Deputy  System  Manager  -  Larry  Deibel,  AFE— 5, 

202-287-8782 

7.  Airport  Surface  System  Manager,  AFE— 6 

The  Airport  Surface  System  Manager  is  responsible  for  system 
integration  and  the  system  architecture  necessary  for  movement  of 
aircraft  and  ground  vehicles  on  the  airport  surface.  Areas 
include  airport  design  and  operations  issues,  landing  aids, 
surveillance,  and  surface  automation.  The  Airport  Surface  System 
Manager  is  also  responsible  for  linkages  between  airport  and 
facilities  and  equipment  (F&E)  capital  development  planning  and 
coordination.  The  Airport  Surface  System  Manager  also  is  the 
program  manager  for  the  PAA's  runway  incursion  program. 


Points  of  contact  for  the  Airport  Surface  Domain  are: 

-  System  Manager  -  Mike  Harrison,  AFE-6,  202-287-7096 

B.  Associate  Program  Manager  For  System  Engineering 

The  Associate  Program  Manager  for  System  Engineering  (APMSE) 
addresses  system— level  issues  associated  with  project 
requirements,  and  project  interfaces  with  other  NAS  subsystems. 
The  APMSE  participates  in  matrix  management  team  meetings,  and  is 
responsible  for  acting  on  behalf  of,  and  representing  the  program 
manager  (PM)  to  the  ASD  system  engineering  support  organizations 
concerning  the  conduct  of  required  system  engineering  activities. 
As  the  designated  representative  to  the  PM,  the  APMSE  acts  as  the 
system  engineering  support  focal  point  for: 

o  Clarification,  analysis,  and  update  of  NAS  system— level 
baseline  requirements  (contained  in  NAS— SR— 1000,  NAS-DD- 
1000,  NAS— SS— 1000,  and  Interface  Requirements  Documents) 
which  serve  as  a  basis  for  the  project  and  its  next  key 
decision  point  (KDP) ;  and,  the  analysis  of  new,  or  proposed 
NAS  system— level  changes  that  have  been  identified  since  the 
project  was  initiated  at  KDP  #1 

o  Refinement  of  developmental  requirements  for  new  NAS 

subsystems,  and  improvements  to  existing  NAS  subsystems  to 
assure  that  research  and  development  (R&D)  products  are 
successfully  integrated  into  the  NAS 

o  Provision  of  information  on,  and  assistance  with,  system 
engineering  practices,  procedures,  and  policies;  including 
engineering  specialties,  software  engineering,  and 
configuration  management 

o  Requests  for  and  provision  of  cost/benefit  analyses  by  AOR, 
and  facility  system  engineering  support  by  AFE,  to  include 
the  coordination  of  facility  requirements,  beginning  with 
the  timely  development  and  approval  of  facility  Interface 
Requirements  Documents  and  continuing  through  the  project's 
deployment  phase 

o  Update  of  the  mission  needs  analysis  (documented  in  the 

Mission  Need  Statement)  that  serves  as  a  basis  for  KDP's  2, 
3,  and  4,  as  required 

o  Input  to,  and  review  of,  project  engineering  documentation 
(e.g.,  specifications,  SOWS,  RFPs,  MTPs) ,  naS  and 
engineering  change  proposals  (NCPs  and  ECPs) ,  and  other  NAS 
subsystem  documentation  for  conformance  with  system 
engineering  policies,  standards,  and  baseline  specifications 


o  Provision  of  technical  support  from  ASE,  AOR,  and  AFE 
functional  divisions  to  resolve  specific  project  needs 

o  Resolution  of  system  issues  that  arise  in  connection  with 
development  and  implementation  of  a  specific  project 

o  Assessment  of  related  functional  area  projects  to  assure 
consistency  among  functional  and  performance  requirements, 
and  project  interdependencies 

o  Provision  of  information  on  the  strategic  planning  for  the 
evolution  of  the  NAS 

o  Participation  in  market  research  efforts  to  determine 

applicability  of  commercial  of f-the-sheif /non-developmental 
items  (COTS/NDI)  to  meet  project  requirements 


The  APMSE  points  of  contact  are  listed  below: 

_ Support  Area _ APMSE _ Telephone 


Advanced  Automation 

John  Scardina,  ASE-100 

287-8611 

En  Route  Automat ion /TMS 

John  Kefalotis,  ASE-100 

646-2098 

Oceanic 

Jim  Wetherly,  ASE-100 

287-8618 

Terminal  Automat ion /ARTS 

II 

Mike  McVeigh,  ASE-100 

287-7115 

Terminal  Automat ion /ARTS 

III 

Mike  McVeigh,  ASE-100 

287-7115 

Flight  Service  Stations 

George  Barboza,  ASE-100 

287-8614 

Weather  Processors 

Vince  Schultz,  ASE— 100 

287-8620 

Weather  Sensors 

Michael  Porter,  ASE-100 

287-8619 

Weather /AWPG 

Vince  Schultz,  ASE-100 

287-8620 

Weather/ITWS 

Michael  Porter,  ASE-100 

287-8619 

TATCA 

John  Kefalotis,  ASE-100 

646-2098 

Airport  Surface 

Jay  Merkle,  ASE-100 

287-8759 

Data  Link/Applications 

Kevin  Grimm,  ASE— 100 

287-8752 

Data  Link/Communications 

Rus  Zub,  SEIG 

646-2251 

Sate  11 ite/Communi cat  ions 

Greg  Burke,  ASE-200 

287-8628 

Satellite /Navigation 

Charles  Rosario, ASE-300 

287-8637 

Support  Area 

APMSE 

Telephone 

Non— ACF  Voice  Switches, 
Recorders;  ETVS,  ICSS, 

STVS,  RDVS,  HCVR,  TVSR 

Maj  Sheila  Giscombe, 
USAF.  ASE-200 

287-8652 

Air/Ground  Communications, 
Gulf  of  Mexico;  RCE, 
Emergency  Transceivers, 

RFI  Elimination, 

Transceiver  Replacement, 

BUEC 

Hoang  Tran,  ASE-200 

287-8626 

Interfacility  Communi¬ 
cations;  DLP  1  S  2, 

NADIN  II,  RCL,  LDRCL, 

RCR,  DMN,  INMS 

Dawn  Abel,  SEIC 

646-5322 

ACF  Voice  Switches/ 

Voice  Switching  and 

Control  System  (VSCS) 

Pete  Holleran,  SEIC 

646-5619 

Distance  Learning  System 

Terry  Wendel,  ASE-200 

287-8627 

Landing  Systems 

Tom  Laginja,  ASE-300 

287-8635 

Navigation  Systems 

Greg  Joyner,  ASE-300 

287-8634 

Terminal  Radar/ASR-9,  TRDRE 

Jim  Chen,  ASE-300 

287-8636 

Terminal  Radar/ASDE-3 

Charles  Rosario, ASE-300 

287-8637 

Secondary  Radar 

Doug  Hodgkins,  ASE-300 

287-8633 

En  Route  Radar/ARSR-4 

Jim  Chen,  ASE-300 

287-8636 

Weather  Radar 

ASE-300 

287-8630 

Terminal  Sensors  (R&D) 

Jim  Chen,  ASE-300 

287-8636 

Maintenance  Automation 

John  Snow,  ASE-600 

287-7114 

Program 

Lessons  Learned 

Mission  need  statements  are  viewed  as  instruments  for  obtaining 
funding  rather  than  providing  the  information  relevant  to  support 
the  key  decision  point  process. 

Many  mission  need  statements  are  written  to  support  specific 
technologies  or  solutions  rather  than  describing  the  operational 
capability  shortfall  that  needs  attention. 


System  performance  requirements  are  easy  to  defend  when  they  have 
an  operational  and  analytic  basis. 

Skipping  steps  in  the  acquisition  process  results  in  significant 
rework,  cost  overruns  and  schedule  delays. 

70%  to  80%  of  a  system's  life  cycle  cost  is  the  result  of 
decisions  made  early— on  in  the  acquisition  process. 

Focusing  on  finding  the  optimal  solution  to  a  vaguely  stated 
problem  description  is  a  mistake.  It  results  in  increased 
requirements  changes,  increased  cost  and  schedule  slips. 

Process  and  product  are  inseparable. 

PM' s  should  contact  the  APMSE  immediately  after  becoming  aware  of 
problems  in  the  system  requirements  area  so  that  a  timely 
resolution  can  be  accomplished. 

Major  conflicts  and  disconnects  are  minimized  with  proper 
coordination  between  FAA  operating  elements,  project  offices,  and 
System  Engineering  offices. 

The  requirements  process  should  be  followed  so  that  NAS 
requirements  are  consistent  and  traceable  from  conception  through 
implementation . 

Responsibilities 

Needs  identification  and  requirement  responsibilities  are 
assigned  as  follows : 

o  Air  Traffic  and  Flight  Standards  -  Responsible  for 
identifying  operational  needs  and  operational 
requirements 

o  NAS  Operations  Service  (AOP)  -  Responsible  for 
identifying  telecommunications  management  and 
operations  needs 

o  NAS  Transition  and  Implementation  Service  (ANS)  - 
Responsible  for  identifying  transition  and 
implementation  requirements 

o  Operational  Support  Service  (AOS)  -  Responsible  for 

identifying  second  level  maintenance  requirements  for 
operational/ support  software  and  hardware  brought  into 
the  NAS 
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o 


Requirements  and  Life-Cycle  Management  Service  (ALM)  ~ 
Responsible  for  NAILS  requirements,  assessing  system 
performance  and  supportability  and  providing  this 
information  to  FAA's  mission  need  analysis  process 

o  Operations  Research  Service  (AOR)  -  Responsible  for 
the  mission  needs  analysis  team  (MNAT)  that  supports 
sponsoring  organizations'  development  of  mission  need 
statements  and  performing  mission  area  analysis  to 
identify  and  forecast  operational  needs.  In  addition, 
AOR  is  responsible  for  cost  estimating  and  benefit/cost 
analyses . 

o  NAS  System  Engineering  (AFE  and  ASE)  -  Responsible  for 
supporting  the  mission  need  analysis  team  and 
supporting  sponsoring  organizations  in  transforming  an 
approved  mission  need  into  an  Operational  Requirements 
Document,  and  allocation  of  those  requirements  as 
indicated  below: 

[]  Facility  System  Engineering  (AFE) 

AFE  is  responsible  for  providing  system 
engineering  direction  for  the  integration  of  NAS 
equipment  into  FAA  facilities;  developing  space, 
electrical,  and  heating,  ventilation,  and  air 
conditioning  (HVAC)  requirements;  developing 
generic  facility  designs;  maintaining 
configuration  control  of  facility— to— subsystem 
IRDs  and  Volume  VI  of  NAS  — SS— 1000;  serving  as  co- 
chair  of  the  NAS  Facilities  Configuration  Control 
Board  (ANFCCB) ;  developing  facility— related  FAA 
standards,  specifications  and  orders;  ensuring 
that  facilities,  as  systems,  are  responsive  to  the 
FAA  and  end  user  needs;  providing  facility— related 
support  to  NAS  program  managers;  and  support 
Capital  Investment  Plan  activities  related  to 
facilities 

_  AFE— 100  is  responsible  for  Air  Route  Traffic 

Control  Centers  (ARTCC) ,  Area  Control  Facilities 
(ACF) ,  Metroplex  Control  Facilities  (MCF) ,  Flight 
Service  Stations  (FSS),  facilities  related  to 
National  Traffic  Flow  Management,  unmanned 
facilities,  and  the  Facility  System  Analysis  Tool 
(FSAT)  Radar  Approach  Control  (TRACON)  (Metroplex) 
control  facilities 

_  AFE-200  is  responsible  for  Airport  Traffic  Control 

Towers  (ATCT) ;  Terminal  Radar  Approach  Control 
Facilities  (TRACON) ;  Local  Control  Facilities 
(LCF) /  electrical  systems,  HVAC  systems;  facility 
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configuration  management;  support  of  Department  of 
Defense  base  closure  activities;  human  factors, 
environmental,  energy  and  safety  issues;  the  Power 
System  Analysis  Tool  (PSAT) ;  and  facility— related 
standards,  specifications,  and  orders 

[  ]  NAS  System  Engineering  (ASE) 

ASE  is  responsible  for  system— level  requirements, 
functional  requirements,  interface  requirements, 
performance  requirements,  communications 
standards,  engineering  standards  and  the 
maintenance  of  NAS-SR-1000,  NAS-DD-1000,  and  NAS- 
SS— 1000  (Volumes  I  through  V) 

_  ASE-100  is  responsible  for  automation  and  weather 

systems  engineering 

_  ASE— 200  is  responsible  for  communications  systems 

engineering,  communications  and  protocol 
standards,  and  the  communications  portion  of 
Interface  Requirements  Documents 

_  ASE— 300  is  responsible  for  systems  engineering  in 

the  areas  of  surveillance,  navigation  and  landing 
systems 

_  ASE-600  is  responsible  for  engineering 

specialties,  interface  management,  test  and 
evaluation  policy,  NAS  software  engineering,  the 
Maintenance  and  Operations  support  element  and 
updates  NAS-SR-1000,  NAS-DD-1000  and  NAS-SS-1000 
based  on  approved  NAS  Change  Proposals 

_  ASE-3  is  responsible  for  NAS  Configuration 
Management,  the  Specification  Review  board, 
ensuring  the  integrity  of  NAS  System  Engineering 
Service  support  for  FAA's  acquisition  process,  and 
the  development  and  application  of  sound  system 
engineering  polices  and  procedures  for  NAS 
evaluation 

Program  Managers 

Program  managers  are  responsible  for  ensuring  that 
subsystem  performance  and  functional  requirements 
are  traceable  to  mission  need  statements, 
operational  requirements  documents,  and  NAS 
baseline  documents  NAS-SR-1000,  NAS-DD-1000,  and 
NAS-SS-1000;  other  requirements  should  be 
traceable  to  the  applicable  standards  and  orders 


Review  and  Approval 


The  following  requirements-related  items  are  reviewed  and 
approved  as  follows: 

o  Mission  Need  Statement  -  Review  and  approval  per  Order 
1810. IF/  Acquisition  Policy 

o  NAS-SR-1000  Changes  -  Review  by  "must  evaluators"  and 
approval  by  the  NAS  Configuration  Control  Board  (CCB) 
(NCP  is  required) 

o  NAS— DD— 1000  Changes  -  Review  by  "must  evaluators"  and 

approval  by  the  NAS  CCB  (NCP  is  required) 

o  NAS— SS  — 1000  Changes  -  Review  by  "must  evaluators"  and 

approval  by  the  NAS  CCB  (NCP  is  required) 

o  Engineering  Standards  (New)  -  Review  by  SRB  members  and 
approval  by  the  NAS  CCB  (NCP  is  required) 

o  Engineering  Standards  Changes  “  Review  by  "must 
evaluators"  and  approval  by  the  NAS  CCB  (NCP  is 
required) 

o  IRDs  and  Facility  IRDs  -  See  Chapter  12,  Interface 
Management 

o  Project  Specifications  (New)  -  Review  and  endorsement 
by  the  SRB  and  approval  by  the  acquisition  office  CCB 
(NCP  is  required) 

o  Project  Specification  Changes  “  Review  by  "must 

evaluators"  and  approval  by  the  cognizant  acquisition 
office  CCB  (NCP  is  required) 


Contacts 

The  following  organizations  may  be  contacted  for  additional 
information  in  the  areas  indicated: 

o  System  Engineering  Process,  ASE— 3.1,  202—287—8603 

o  Mission  Need  Analysis  Team,  AOR— 100,  202-287—8767 

o  Mission  Need  Statement  Development,  AOR-100, 
202-287-8767 

o  Benefit/Cost  Analyses,  Cost  Estimating,  AOR-100, 
202-287-8509 


System  Requirements,  System  Design,  MNA  Team  Support 
(Review  of  mission  need  statements)  ,  Operational 
Requirements  Documents,  Interface  Requirements 
Documents 

Automation  ^  Weather,  ASE-100,  202-287-8611 

-  Communications,  ASE— 200,  202—287—8621 
Surveillance,  ASE-300,  202-287-8630 

-  Navigation  &  Landing,  ASE— 300,  202—287—8630 

-  Maintenance  &  Operations,  ASE-600,  202-287—8644 

-  Engineering  Specialties,  ASE— 600,  202—287—8644 

-  Software  Engineering,  ASE— 600,  202—287—8646 

Facilities:  ARTCC/ACF/MCF/FSS/Other,  AFE-100, 

202-287-8580 

Facilities:  ATCT/TRACON/LCF,  AFE-200, 

202-287-8583 

IRD  Interface  Management  Process,  ASE-600,  202-287-8655 
Facility  IRDs 

ARTCC/ACF/MCF/FSS/Other,  AFE-100,  202-287-8580 
ATCT/TRACON/LCF,  AFE-200,  202-287-8583 

NAS  Baseline  Document  Updates,  ASE— 600,  202-287-8644 

NAS-SR-1000,  NAS-DD-1000  &  NAS-SS-1000  (Vols .  I  through 

V) 

_  Automation  &  Weather,  ASE— 100,  202—287—8611 
_  Communications,  ASE— 200,  202—287—8621 

_  Surveillance,  ASE— 300,  202-287-8630 

_  Navigation  &  Landing,  ASE— 300,  202—287—8630 
_  Maintenance  &  Operations,  ASE— 600,  202—287—7114 


NAS-SS-1000,  Volume  VI 

ARTCC/ACF/MCF/FSS/Other,  AFE-100,  202-287-8580 
ATCT/TRACON/LCF,  AFE-200,  202-287-8583 

Engineering  Standards,  ASE— 600,  202—287—8644 

Facility  Engineering  Standards,  AFE-200,  202—287—8583 

Communications  &  Protocol  Standards,  ASE— 200, 
202-287-8621 


NAS  Software  Standards,  ASE-600,  202-287-8646 


Reference  Documents 


The  following  documents  are  the  basis  for  the  guidelines 
presented: 

o  Order  1320. ID,  FAA  Directives  System 

o  Order  1800. 8F,  NAS  Configuration  Management 

o  Order  1810. IF,  FAA  Acquisition  Policy 

o  NAS-SR-1000,  NAS  System  Requirements  Specification 

o  NAS-DD-1000,  NAS  Level  I  Design  Document 

o  NAS-SS-1000,  NAS  System  Specification 

Point  of  Contact  for  Chapter  2  is  Joseph  DeMeo,  ASE-3, 
202-287-8602. 


MAJOR  SYSTEM  ENGINEERING  PROCESS  ELEMENTS 
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Chapter  3 


Research,  Engineering  And 
Development  (R,  E&D)  Plan 


Background 

The  Research,  Engineering  and  Development  (R,E&D)  Plan  describes 
the  FAA's  efforts  to  develop  technologies  that  address  both 
current  and  projected  National  Airspace  System  (NAS)  issues  so 
that  our  Nation  can  maintain  a  competitive,  robust  aviation 
infrastructure.  The  Plan  outlines  individual  projects  that  may 
lead  to  new  systems  for  NAS  implementation.  However,  the  R,E&D 
Plan  is  not  the  vehicle  for  putting  new  systems  into  the  NAS, 
that  function  is  accomplished  by  the  Capital  Investment  Plan. 

The  R,E&D  program's  purpose  is  to  determine  solutions  for  defined 
problems  and  develop  the  selected  technology  to  the  point  that  it 
is  a  viable  system.  The  project  is  then  transitioned  to  the 
Capital  Investment  Plan  for  future  NAS  implementation. 

Changing  operational  mission  needs  for  the  NAS  and  revised  FAA 
strategic  policy  guidance  frequently  result  in  new  R,E&D 
requirements.  Therefore,  the  Plan  and  the  process  that  supports 
it  is  evolutionary  rather  than  static.  As  additional  needs  are 
identified,  new  candidate  projects  will  be  created,  submitted  for 
validation  and  approval,  then  processed  through  the  budget  cycle. 
The  mechanism  used  to  identify  and  process  these  new  requirements 
is  the  Mission  Needs  Statement  (MNS)  with  associated  Research 
Project  Initiatives  (RPI) .  Since  annual  authorization  levels 
establish  the  upper  limit  of  R, E&D  funding,  new  and  existing 
projects  must  compete  to  produce  the  FAA's  priority  items  for  the 
annual  budget  submission. 

MNS/RPI  Process  Siimmary 

The  MNS  process  is  the  mechanism  used  to  get  new  projects  into 
the  R, E&D  program  when  a  shortfall  in  existing  capability  has 
been  identified.  Candidate  projects  that  do  not  have  an  MNS  will 
not  be  considered  for  funding.  Figure  3.1  shows  the  MNS  approval 
process  leading  to  Acquisition  Review  Council  KDP-1  approval  for 
projects  with  a  total  cost  greater  than  $50  million  or  that  have 
a  Facilities  and  Equipment  (F&E)  funding  component.  Those 
projects  requiring  only  R,E&D  resources  with  a  total  cost  less 
than  $50  million  will  only  require  Service  Director  approval. 


When  putting  together  an  MNS/RPI  package  it  is  important  to 
remember  that  the  MNS  should  document  a  shortfall  in  capability, 
i.e.,  a  problem.  The  associated  RPIs  should  describe  the  R, E&D 
activities  that  will  be  investigated  in  an  attempt  to  solve  the 
stated  problem.  A  common  deficiency  in  past  MNS  packages  is  that 
they  focused  too  much  on  a  particular  technology  or  solution 
alternative  without  describing  a  problem.  The  research  project, 
not  the  MNS  package,  is  tasked  with  determining  what  technology 
or  solution  is  best  based  on  quantitative  data  after  examining 
all  the  alternatives.  FAA  Order  1810. IF  provides  a  detailed 
description  preparing  MNSs  and  the  MNS  process. 

R,E&D  Process  Simmary 

This  section  provides  a  brief  overview  on  the  R,E&D  budgeting 
process.  Figure  3.2  is  a  highly  condensed  guide  showing  the 
major  steps  required  to  develop  resource  allocations  for  the 
R, E&D  budget.  The  Resource  Allocation  Subcommittee  (RAS) 
develops  system  issues  designed  to  solicit  broad,  top  down  policy 
guidance  from  the  Steering  Committee  or  upper  management  as 
appropriate.  The  system  issue  guidance  is  then  applied  to 
existing  R, E&D  programs  and  new  MNSs.  The  chapter  managers 
develop  recommendations  for  project  funding  based  on  the 
allocations  the  RAS  set  for  their  chapters.  These 
recommendations  are  reviewed  by  the  RAS  and  sent  to  the  Steering 
Committee  for  final  approval. 

R, E&D  Plan  Development  Cycle 

R,E&D  Plan  development  begins  in  April  after  the  budgeting 
process  and  Congressional  appropriations  hearings  are  completed. 
There  is  only  one  draft  produced  before  a  final  draft  is  sent  for 
upper  management  review.  To  produce  draft  1  APM— 300  will  contact 
the  managers  for  new  and  existing  projects  to  schedule  a  R, E&D 
Plan  project  description  development/review  session.  At  these 
sessions  APM  will  explain  the  requirements  the  project 
description  needs  to  fulfill  and  assist  the  program  managers  in 
developing  a  description  for  new  projects  or  editing  the 
description  for  existing  projects.  The  R, E&D  Plan  is  a  high- 
level  document  designed  to  give  a  basic  overview  of  the  FAA's 
entire  R,E&D  program  to  a  non-technical  audience.  Once  draft  1 
is  completed  it  will  be  distributed  to  the  Associate 
Administrators  for  agency— wide  review.  All  comments  received 
will  be  coordinated  through  the  program  managers  before  being 
incorporated  into  the  final  draft.  The  final  draft  then  enters 
upper  management  review  by  AOA-3,  AOA-2,  and  AOA-1  before  being 
sent  for  OST/OMB  review.  When  the  plan  finishes  the  OST/OMB 
review  it  is  processed  through  AOA-3,  AOA-2,  and  AOA-1  for  final 
signature  and  publication. 

The  point  of  contact  for  Chapter  3  is  Kevin  Bridges,  APM-300, 
202-287-8722 . 
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Chapter  4 


Capital  Investment  Plan 


Background 

The  Capital  Investment  Plan  (CIP)  summarizes  Facilities  and 
Equipment  (F&E)  programs  that  the  FAA  intends  to  pursue  over  a  15 
year  planning  horizon  in  addressing  key  concerns  of  the  National 
Airspace  System  (NAS) .  The  CIP  embodies  the  phased  plan  for 
evolution  of  the  existing  NAS  through  an  orderly  deployment  of 
new  products  and  technologies  to  meet  mission  need.  New  F&E 
programs  are  identified  through  a  continuous  process  of  mission 
need  analysis  which  leads  to  development /approval  of  a  mission 
need  statement  (MNS) .  Approved  MNS  then  enter  the  competition 
with  existing  programs  for  F&E  funding  each  year,  in  the  F&E 
budget  process.  Major  CIP  program  objectives  are  to: 

1.  Provide  for  growth  through  expansion,  relocation,  or 
consolidation  of  F&E 

2.  Refurbish  structures,  replace  obsolete  equipment,  or 
relocate  facilities  to  maintain  service,  improve 
effectiveness,  and/or  reduce  cost 

3.  Provide  spares,  train  personnel,  and  manage  the  human 
aspect  of  modernizing  the  NAS 

4.  Add  new  capabilities  to  the  System 

The  F&E  budget  process  is  closely  interwoven  with  CIP  development 
and  annually  allocates  resources  according  to  the  approved 
Capital  Investment  Plan.  By  updating  the  CIP  and  formulating  the 
F&E  budget  concurrently,  the  FAA  ensures  its  scarce  resources  are 
targeted  at  the  most  critical  mission  needs. 

Overall  CIP  Development  Process 

A  new  process  for  capital  investment  planning  linked  to  budget 
development  has  been  developed  (see  Figure  4.1).  The  new  process 
involves  three  major  sequential  phases  of  planning  and  budget 
development:  (1)  initial  policy  guidance,  which  is  provided  top- 

down  by  the  Administrator  and  CIP  Steering  Committee  (Associate 
level) ,  especially  as  to  the  resolution  of  major  system-level 
issues  affecting  the  future  NAS  architecture;  (2)  system 
engineering/operational  analysis.  Using  the  top-down  guidance. 
Functional  Working  Groups  (FWGs)  develop  evaluations  of  all 


CIP/F&E  projects  within  their  respective  functional  areas  and  a 
System  Engineering/Operational  Analysis  Team  (SEOAT)  (Service 
Director  Level)  develops  an  FAA-wide  Resource  Allocation  of  all 
CIP/F&E  projects;  and  (3)  the  EWG  under  the  SEOAT  allocate  F&E 
resources  to  individual  CIP  projects  according  to  their  corporate 
evaluation  and  their  executability  for  the  F&E  budget  planning 
year.  FWG  members  are  assigned  by  the  SEOAT. 

The  1994  CIP  planning  and  the  FY  1996  budget  processes  began  with 
the  late  July  notification  of  a  submittal  deadline  for 
preliminary  MNSs  (see  Figure  4.1),  which  was  just  a  reminder  of 
the  October  15  deadline  for  submittal  for  the  planning  year;  it 
is  not  a  starting  point.  Inputs  (MNSs,  FBCNs,  and  NCPs)  should 
be  processed  throughout  the  year.  Those  inputs  which  identify 
new  funding  requirements  above  the  current  CIP  baseline  and 
requesting  FY  1996  funding  were  due  to  APM  by  October  15,  1993. 

In  September,  ABU  initiated  a  budget  Call  for  early  submission  by 
program  offices  and  regions.  In  the  "early"  submission,  program 
offices  were  required  to  submit  FY  1996  F&E  resource  requirements 
sorted  by  work  breakdown  structure  (WBS)  elements.  Also,  in 
November,  regions  submitted  only  a  prioritized  list  of  specific 
sites  to  be  evaluated  for  national  program  funding  (e.g.,  ATC 
Modernization)  .  The  early— submission  data  received  from  the  call 
will  be  used  for  both  the  1994  CIP  planning  and  the  FY  1996 
budget  process. 

The  planning  and  resource  allocation  process  will  be  developed  in 
three  phases  (see  Figure  4.2).  In  Phase  I  the  CIP  Steering 
Committee  and  Administrator  will  decide  on  major  system-level 
issues  initially  collected  by  the  SECAT,  and  develop  guidance  for 
Phase  II.  In  Phase  II/  all  projects  in  the  CIP  will  be  rated  and 
evaluated  by  their  ability  to  achieve  Agency  goals  and  their 
contribution  to  resolving  the  system— level  issues.  No  funding 
will  be  considered  during  the  first  two  phases.  All  new  Mission 
Need  Statements  (MNSs) ,  Financial  Baseline  Change  Notices 
(FBCNs) ,  and  NAS  Change  Notices  (NCPs)  requirements  for  FY  1996 
will  be  evaluated  during  the  second  phase  and  their  funding 
levels  incorporated  into  the  financial  baseline  to  be  used  during 
the  third  phase  of  the  process.  The  Third  phase  will  develop  the 
funding  profiles  for  all  projects  and  the  final  CIP  financial 
baseline . 

First  CIP  Steering  Committee  Conference 

The  first  CIP  Steering  Committee  Conference  will  be  held  at  or 
near  FAA  Headquarters.  At  this  conference,  the  major  issues  will 
be  reviewed  and  approved,  and  the  Associate  Administrators  will 
collectively  review  and  discuss  changes  submitted  through  the 
MNS,  NCP,  and  FBCN  processes.  After  the  conference,  the 
Associate  Administrator  for  Systems  Engineering  and  Development, 
ASD,  will  revise  the  major  issues  (as  required)  and  forward  to 
the  FAA  Administrator  for  final  approval.  The  Administrator 


approved  major  issues  will  be  provided  to  the  SEOAT  and  FWGs  for 
rating  the  CIP  projects. 

Initial  Draft  of  CIP 


The  initial  draft  of  the  new  CIP  will  use  the  last  published  CIP 
as  a  starting  point.  Projects  which  have  been  completed  since 
the  publication  of  the  last  CIP  will  be  deleted.  Each  project 
remaining  in  the  plan  will  be  updated  by  APM— 300  through 
interviews  with  the  program  managers.  CIP  project  milestones 
will  also  be  updated  as  appropriate  through  APM— 300  conducted 
joint  reviews  with  the  program  managers.  These  reviews  will 
update  the  milestones  to  incorporate  0MB  and  congressional 
actions  on  the  budget.  Project  descriptions  will  be  developed 
for  MNSs  approved  by  the  ARC  and  those  which  are  expected  to  be 
scheduled  for  an  ARC  decision  by  mid— February .  New  project 
descriptions  will  be  based  on  the  information  provided  in  the  MNS 
in  coordination  with  the  MNS  originator  and  sponsor. 

Chapter  one  and  the  other  chapter  introductions  will  be  updated 
by  APM— 300  in  coordination  with  personnel  in  key  specialty  areas. 
In  addition,  applicable  strategic  information  developed  during 
SEOAT  and  FWG  deliberations  will  be  included.  To  facilitate  the 
review  process,  new  and  deleted  text  will  be  identified  using 
underlining  and  strikeouts.  The  initial  draft  will  be 
distributed  for  associate  level  review  in  January,  well  before 
the  second  CIP  Steering  Committee  Conference  offsite. 

Second  CIP  Steering  Committee  Conference 

This  offsite  conference  is  held  to  report  on  the  actions  taken  by 
the  FWG  and  the  SEOAT,  and  to  align  the  F&E  funding  profile  with 
the  CIP  projects.  The  conference  agenda  will  include  briefings 
by  the  FWG  and  SEOAT  on  CIP  ranking,  content,  and  issues;  a 
status  report  from  ACQ  on  all  Mission  Need  Statements;  a  briefing 
by  the  NAS  Planning  Division  on  the  status  of  the  draft  CIP  and 
changes  made  since  the  previous  issue;  F&E  budget  status;  and 
briefings  by  the  DOD  and  the  Regions,  as  required.  The  Regions 
have  the  opportunity  to  express  their  views  on  any  issues  related 
to  the  CIP  through  their  NAS/CIP  coordinators.  This  is  the  forum 
to  resolve  any  issue  resulting  from  changes  to  Draft  1  and  to 
surface  new  issues. 

Final  Draft  of  CIP 


The  final  draft  of  the  CIP  will  be  a  thoroughly  coordinated 
document  that  will  be  reviewed  and  approved  by  the  Administrator. 
This  draft  will  then  be  submitted  along  with  the  budget  to  the 
Office  of  the  Secretary  of  Transportation  (OST) .  it  will  include 
comments  from  the  initial  Draft,  results  of  funding  adjustments, 
and  approvals  of  Mission  Need  Statements.  All  technical,  cost, 
and  schedule  data  will  be  coordinated  and  be  in  alignment  for 


this  draft.  In  addition,  the  final  draft  will  be  used  as  the 
vehicle  to  accomplish  the  following: 

A.  ADA/AOA  Review:  Review  of  the  CIP  by  the  Deputy 
Administrator  (ADA— 1)  and  the  Administrator  (AOA-1)  will 
be  accomplished  using  this  draft.  The  Administrator  will 
be  briefed  on  all  new  CIP  initiatives  and  other 
significant  factors,  so  that  his  policy  decisions  can  be 
reflected  in  the  OST  budget. 

B.  Schedule  Validation:  During  the  preparation  of  the  final 
draft,  there  will  be  a  CIP  schedule  validation  and 
approval  of  all  CIP  project  milestones.  This  validation 
and  approval  will  be  conducted  by  a  joint  coordinated 
effort  among  the  Associate  Administrators  and  their 
various  Service  Directors,  Program  Directors,  and  the 
Division  and  Branch  Managers.  The  CIP  schedule  database 
will  be  updated  with  the  approved  schedules . 

Camera  Ready  Copy  of  the  CIP 

The  Administrator  will  approve  the  Plan  for  publication  after 
resolution  of  OST/OMB  comments  and  any  modification  for 
conformance  of  the  Plan  with  the  current  budget  submission  to 
Congress .  The  document  will  then  be  printed,  distributed,  and 
made  available  to  the  public. 

A.  Any  changes  resulting  from  OST  actions  on  the  budget  will 
be  incorporated  in  the  schedules. 

B.  This  document  will  be  reviewed  for  completeness  in 
layout,  spelling,  and  editing.  Approach  and  technical 
content  cannot  be  changed;  however,  milestones  that  occur 
near  the  publishing  date  will  be  changed  to  reflect  their 
actual  status . 

Point  of  Contact  for  Chapter  4  is  Edwin  Camacho,  APM— 300, 
202-287-8723. 
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Chapter  5 


FAA  Budget  Process 


This  chapter  provides  information  on  the  FAA  budget  process. 

Process  Description 

There  are  three  phases  in  the  budget  process: 
o  Formulation 

o  Congressional  Action 

o  Execution 

Each  of  these  is  interrelated  with  the  others.  The  time  span 
from  the  beginning  to  completion  of  all  three  phases  for  a  single 
budget  year  depends  on  which  appropriation  is  being  used,  but  for 
the  longest.  Facilities  and  Equipment  (F&E) ,  the  period  is  more 
than  five  calendar  years. 

Budget  Formulation 

Depending  on  the  appropriation,  the  FAA  budget  cycle  begins  as 
early  as  26  months  before  the  start  of  the  fiscal  year  to  which 
the  budget  will  pertain,  with  the  issuance  of  "Call"  documents  by 
the  Office  of  Budget  (ABU) .  For  Facilities  and  Equipment  (F&E) , 
a  draft  Call  is  developed  in  July  and  a  working  copy  is  forwarded 
to  the  regions  in  August,  to  begin  preparation  of  project  data. 

A  separate  document  is  issued  by  ABU  for  the  following 
appropriations : 

o  Facilities  and  Equipment  (F&E) 

o  Research,  Engineering  and  Development  (R,E&D) 

o  Operations  (OPS) 

These  documents  establish  the  basis  for  developing  funding  and 
staffing  needs  for  one  or  more  future  budget  years. 

The  regional  budget  offices  assist  the  field  or  regional  program 
divisions  to  "price  out"  their  requirements,  provide  advice  on 
the  requirements  and  the  associated  justifications,  and 
consolidate  and  summarize  the  division  submissions  (with  staff 
and  support  submissions)  into  a  single  regional  submission  —  for 


each  activity  in  the  Operations  appropriation.  The  regional 
administrator  transmits  the  consolidated  submission  without 
making  any  changes  to  regional  program  division  requests  and 
prepares  and  submits  a  critique  of  the  budget  and  its  balance  (or 
lack  thereof)  to  ABU.  The  Washington  program  offices  and  ABU 
review  submissions  of  the  various  budget  activities. 
Recommendations  are  presented  to  the  Administrator  who  makes  the 
final  decision  as  to  what  is  sent  to  the  Office  of  the  Secretary 
of  Transportation  (OST)  in  June. 

OST  conducts  its  review  of  the  FAA  request  and  makes  certain 
program  decisions,  and  changes  to  the  level  of  dollars,  positions 
or  full-time  equivalents  (FTEs)  requested  by  the  FAA.  Once  OST 
has  made  its  determinations,  the  FAA  may  appeal  to  the  Secretary 
for  restoration  of  all  or  part  of  the  deleted  programs  or 
resources.  After  reconsideration  and  advice  from  OST  on  the 
appeal,  the  budget  is  submitted  to  the  Office  of  Management  and 
Budget  (0MB)  in  September  for  further  review  and  hearings. 

In  late  November,  0MB  gives  the  FAA  a  "passback"  consisting  of 
dollars  and  positions/FTEs  that  0MB  will  recommend  for  inclusion 
in  the  President's  budget  request  to  Congress.  Depending  on  the 
nature  of  the  0MB  "passback",  the  FAA  may  decide  to  appeal  (with 
the  concurrence  of  OST)  to  the  0MB  for  restoration  of  all  or  part 
of  the  funds  or  positions/FTEs.  Following  a  new  decision  or 
action  by  0MB,  the  FAA  prepares  its  official  budget  to  be 
included  as  part  of  the  President's  budget  submission  to 
Congress . 

Congressional  Action 

The  President's  annual  budget  is  usually  transmitted  to  Congress 
on  the  first  Monday  in  February  (per  0MB  Bulletin  93-03  and  the 
Budget  Enforcement  Act  of  1990) .  This  transmittal  starts  the 
congressional  phase  of  the  budget  process.  After  submission  of 
the  President's  Budget,  the  FAA  prepares  a  submission  consisting 
of  more  detailed  data  and  justifications  for  the  resources 
requested  in  the  budget. 

Before  considering  appropriations  for  a  specific  program. 

Congress  must  enact  enabling  legislation  (i.e.,  authorizing  an 
agency  to  carry  out  that  program) .  Such  legislation  provides  the 
legal  basis  for  appropriating  funds  to  the  FAA  and  may  also  set 
limitations  on  the  amount  of  money  that  can  be  appropriated. 
Programs  may  have  permanent  authorization  or  may  be  authorized  to 
operate  during  a  specific  timeframe. 

The  Congressional  appropriations  process  begins  with 
appropriations  hearings,  usually  in  a  House  subcommittee.  After 
those  hearings,  the  subcommittee  prepares  a  report  with 
recommendations  for  appropriations  to  the  FAA  and  other  DOT 
agencies.  The  full  Appropriations  Committee  then  introduces  a 


bill  to  the  full  House.  The  House  votes  on  the  bill  and  forwards 
it  to  the  Senate.  The  FAA  and  OST  may  appeal  to  the  Senate  if 
the  House  has  reduced  programs  or  resources  requested  by  the 
President.  Then  a  similar  process  is  followed  with  the  Senate 
Appropriations  Subcommittee.  If  the  dollar  amounts  between  the 
two  Congressional  bodies  differ,  a  joint  conference  convenes  in 
order  to  resolve  the  discrepancy.  When  the  conferees  have 
reached  agreement,  both  the  full  House  and  Senate  vote.  The  end 
result  of  these  deliberations  is  an  appropriations  bill  which  is 
enacted  and  forwarded  to  the  President  for  signature.  After 
signature  by  the  President,  it  becomes  a  Public  Law,  which 
identifies  specific  levels  of  resources  for  the  FAA  for  the 
fiscal  year  covered,  as  well  as  multiyear  and  no— year  funding  for 
certain  programs.  If  an  appropriations  bill  has  not  been  passed 
by  October  1,  the  Congress  must  pass  a  continuing  resolution 
enabling  the  government  to  continue  operations.  A  continuing 
resolution  is  typically  much  more  constrained  than  proposed 
appropriations . 

Budget  Execution 

During  budget  execution,  funds  in  the  approved  fiscal  year  budget 
are  made  available  to  the  FAA  to  carry  out  its  missions, 
functions,  and  programs.  Through  apportionments  issued  by  0MB, 
funds  are  made  available  for  obligation  on  a  time-phased  basis . 
Upon  0MB'' s  approval  of  its  apportionment  request,  ABU  issues 
allotments  based  on  the  initial  operating  plans  developed  by  the 
regions,  centers,  and  Washington  program  offices. 

Currently,  ABU  issues  "allowances"  to  PMs  in  Washington  and  the 
regions.  Allowances  are  similar  to  allotments  in  that  they 
provide  obligational  authority  to  the  individual  receiving  the 
allowance.  As  with  allotments,  allowances  are  adjusted  based  on 
the  receipt  of  a  revised  operating  plan  that  has  been  approved  by 
the  appropriate  Washington  program  office. 

Throughout  the  fiscal  year,  the  amounts  issued  may  be  adjusted  by 
ABU,  based  on  revised  operating  plans  and/or  actions  recommended 
by  the  Executive  Resource  Committee  (ERC)  and  approved  by  the 
Executive  Board.  For  example,  when  additional  funds  are  required 
by  a  regional  PM,  a  request  is  forwarded  to  the  Washington 
program  office  for  approval  and  is  then  forwarded  to  ABU  for 
consideration  by  the  ERC/Executive  Board.  If  approved,  ABU 
issues  a  revised  allotment /allowance  to  support  that  increase 
through  the  appropriate  regional  budget  office.  The  ERC  is  used 
initially  to  resolve  operating  policy  issues  and  to  make 
recommendations  on  these  issues  for  Executive  Directors'  approval 
prior  to  issuance  of  funding  adjustments. 


Contacts 


The  following  division  can  be  contacted  for  additional 
information  on  budget  policy: 

O  ABU-100,  202-267-3744 

Reference  Documaits 

The  following  documents  are  the  basis  for  the  guidelines 
presented: 

o  Business  Manager's  Financial  Handbook,  published  October 

1992  (to  be  updated  in  the  May  1994  timeframe) 

o  Order  2500.22,  Call  for  Estimates  “  R/E&D  Appropriation 

o  Order  2500.55,  Call  for  Estimates  ~  Facilities  and 

Equipment 

Point  of  Contact  for  Chapter  5  is  Paulette  Lutjens,  ABU— 100, 
202-267-3744 . 
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0  FINAL  OMB  ALLOWANCE 
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PRESIDENTS  BUDGET 
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CONGRESSIONAL  PHASE 

0  DFP  REVIEW  1ST  QUARTER 

0  PRESIDENTS  BUDGET 
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0  ADJUSTMENTS  TO  RECOVER 
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0  1  ST  QTR  DFP  ADJUSTMEJffK 
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0  PREPARATION  FOR  HEARINGS 

1 _ 

o  ISSUE  PA’S  FOR  ZND  QUARTER 

0  APPROPRIATIONS  HEARINGS 

o  DFP  REVIEW  2ND  QUARTER 

0  Q&A  FOR  THE  HEARING 
RECORD 

INSERT  DATA 

1 

o  3RD  QUARTER  FSR 

0  2ND  DFP  ADJUSTMENTS 
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Chapter  6 


NAS  Test  Arid  Evaluation  Policy 


This  chapter  provides  a  reference  to  Order  1810. 4B,  National 
Airspace  System  (NAS)  Test  and  Evaluation  (T&E)  Program  and  to 
the  responsibilities  and  operation  of  the  Test  Policy  Review 
Committee  (TPRC) . 

Process  Description 

The  flow  chart  presented  in  Figure  6.1  provides  an  overview  of 
the  test  and  evaluation  process  for  NAS  programs.  A  complete 
explanation  of  the  process  and  the  terms  used  in  the  process  is 
presented  in  Order  1810. 4B,  Figure  6.2  is  the  test  and 
evaluation  implementation  flow  diagram.  Independent  Operational 
Test  and  Evaluation  is  discussed  in  Chapter  8. 

The  TPRC  meets  approximately  bimonthly  to  consider  T&E  policy, 
TEMPS,  T&E  policy  waivers,  and  any  other  business  concerning  T&E. 

The  secretariat  that  assists  the  TPRC  chairperson  in  conducting 
the  meetings  is  ASE— 600.  The  TPRC  meeting  agenda  is  established 
by  ASE-600. 

Three  weeks  prior  to  the  TPRC  meeting  date,  ASE-600  receives  the 
updated  TEMPs  and  briefing  packages  from  the  PM.  Two  weeks  in 
advance  of  a  scheduled  TPRC  meeting,  ASE-600  sends  the  meeting 
agenda  and  briefing  packages  to  TPRC  members. 

The  TPRC  is  chaired  by  ASD-2 .  The  TPRC  members  are:  ARD/ANA/ 
ANN/ANR/ANC/ANW/AAP/ANS-200#,  asm,  ASU,  AOS,  ASE-1,  ANS,  ACN/ACD/ 
ATR,  AFS,  ATQ-1**,  AND-6*,  AND-3,  AFE***. 

#  Review  limited  to  projects  within  purview  of  service 
organization 

*  AND-6  Point  of  Contact  for  DOD  Representative  on  Joint 
Procurements  only 

**  MAs  and  subsystems  designated  for  Independent  Operational 

Test  and  Evaluation  (lOT&E)  oversight  only 

***  For  ANS-200  projects  only 


Lessons  Learned 


The  PM  must  become  familiar  with  the  test  policy.  The  PM  should 
also  be  conversant  with  the  latest  revision  to  Order  1810.4. 

Select  a  proficient  APMT .  The  key  to  a  successful  T&E  program  is 
to  have  good  support.  Use  the  APMT  for  early  strategy  sessions 
to  frame  out  the  program's  T&E  for  both  DT&E  and  OTLE. 

The  PM  should  schedule  the  review  of  documentation  requiring  TPRC 
approval  with  ASE— 600  well  ahead  of  time  so  that  there  are  no 
schedule  conflicts. 

Responsibilities 

The  following  T&E  responsibilities  for  PMs  are  extracted  from 
Order  1810. 4B: 

o  Develop  project  VRTM  and  incorporate  into  project 

specifications  prior  to  SRB  approval.  If  the  project  is 
beyond  SRB,  develop  a  project  VRTM  from  the  subsystem 
specification,  per  FAA— STD— 024  (latest  version) ,  and 
Appendix  1  Part  6  of  Order  1810. 4B,  and  incorporate  it 
into  the  project  specification.  Requirements  in  VRTM 
should  also  come  from  Operational  Requirements  Document 
(ORD)  . 

o  Supervise  accomplishment  of  the  project  by  the  contractor 

o  Prepare  a  program  directive  with  the  FAA  Technical  Center 

to  monitor  or  conduct  DT&E,  direct  and  conduct  OT&E 
Integration  and  Operation,  coordinate  OT&E  shakedown,  and 
approve  the  budget  for  these  testing  activities 

o  Prepare  a  program  directive  with  ASU  to  witness  PAT&E 
(contractor  conducts  PAT&E) 

o  Include  test  and  evaluation  in  the  Program  Master  Plan 

o  Prepare  the  TEMP  jointly,  with  the  APMT  taking  the  lead 

o  Coordinate  T&E  requirements  with  DOD  on  joint  procurement 

o  Prepare  test  policy  waiver  requests,  if  necessary 

o  DT&E  requirements  are  taken  from  the  VRTM  in  the 
specification 

o  Monitor  DT&E/PAT&E  conducted  by  contractor 
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O  Incorporate  test  requirements  (DT&E  and  PAT&E)  into  the 
procurement  package.  NOTE:  specification  requirements 
taken  from  NAS-SS-1000.,  ORD  are  incorporated  into 
procurement  package.  These  requirements  drive  contractor 
testing  -  DT&E/PAT&E. 

0  Coordinate  FAA  TEMP  approval  with  ASE— 600  prior  to  TPRC 
distribution,  and  request  for  TPRC  approval 

o  Present  FAA  TEMPs,  waivers  and  test  issues  to  the  TPRC 
jointly  with  the  APMT 

The  following  responsibilities  pertain  to  the  TPRC: 

o  ASD-2  is  responsible  for  chairing  the  TPRC  meetings 

o  ASE-600  is  responsible  for  TPRC  secretariat  functions. 

ASE-600  is  also  responsible  for  revising  and  maintaining 
FAA-STD-024  which  describes  content  and  format 
requirements  for  an  FAA  TEMP. 

o  TPRC  members  are  responsible  for  attending  meetings, 
reviewing  agenda  items  and  briefing  packages,  and 
providing  input  to  the  chairperson 

The  TPRC  is  responsible  for: 

o  Supporting  T&E  policy,  test  standards  and  definitions 

o  Approving  operating  procedures,  FAA  TEMPs  and  revisions 
to  FAA  TEMPs 

o  Approving  test  policy  waivers 

o  Resolving  disagreements  on  T&E  issues  when  agreements 
cannot  be  reached  at  lower  levels  of  FAA  management 

Review  and  Approval 

The  following  items  related  to  T&E  require  review  and  approval  to 

be  in  compliance  with  Order  1810. 4B: 

o  FAA  TEMP  -  Reviewed  and  approved  by  the  TPRC;  the  TEMP  is 
also  reviewed  by  ATQ— 1  for  major  acquisitions 

o  T&E  policy  waivers  “  Reviewed  and  approved  by  the  TPRC; 

those  for  major  acquisition  projects  are  also  reviewed  by 
ATQ-1 

o  Changes  to  FAA  TEMPs  after  TPRC  approval  -  Reviewed  and 

approved  by  the  TPRC;  TEMP  changes  for  major  acquisitions 
are  also  reviewed  by  ATQ-1 


Contacts 


The  following  groups  are  points  of  contact  for  more  information 
regarding  NAS  test  and  evaluation  and  the  TPRC: 

o  Engineering  Specialties  and  Configuration  Management 
Division,  ASE-600,  202-287-8649 

Reference  Document 

The  following  documents  are  the  basis  for  the  guidelines 
presented: 

o  Order  1810. IF,  Acquisition  Policy 

o  Order  1810. 4B,  FAA  NAS  Test  and  Evaluation  Policy 

o  FAA— STD— 024,  Preparation  of  T&E  Documentation 

o  NAS-MD-110,  T&E  Terms  and  Definitions  for  NAS  (NOTE:  we 
will  probably  delete  this  in  1994) 

o  Transportation  Acquisition  Manual  Chapter  34,  Appendix  A, 
Major  Acquisition  Policies  and  Procedures 

Point  of  Contact  for  Chapter  6  is  Rebecca  Taylor,  ASE-600, 
202-287-8649. 
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OVERVIEW  OF  FAA  NAS  TEST  AND  EVALUATION  PROCESS 


-TEST  AND  EVALUATION  PHASES- 


NON-MAs 


MAS  AND 

DESIGNATED 

SUBSYSTEMS 


CONCEPT 

DEMONSTRATION 

DEVELOPMENT 

PRODUCTION 

ACQUISITION  MILESTONES  FOR  MAs  AND  DESIGNATED  SUBSYSTEMS 


KDPl  KDP2  KDP3  KDP4 

•  a  a  a 


1 

Independent  OT&E  Oversight 

- ^ 

1 

■  DEVELOP  MISSION ,  ’  ALTERNATIVE  CONCEPTS 

*  -  DEMONSTRATION 

-  PROTOTYPE  OR  LIMITED 

1  1 

-  FULL  PRODUCTION 

NEED  STATEMENT  *  •  TECHNICAL  RISK  ASSESSMENT]  TESTmC 

1  PRODUCTION  T&E 

1  ACCEPTANCE  TESTINS  1 

(MNS)  1 .  USER  PARTICIPATION 

,  -  FUNCTIONAL  BASELINE 

-OT&E 

AT  EACH  DEPLOYMENT  SITE  i 

a\ 

• 

1 

1  VERinCATION 

>  -INTEGRATION  AND 

i  -  FIELD  SHAKEDOWN  AT 

1 

1  -  USER  PARTICIPATION 

1  OPERATIONAL 

1  EACH  DEPLOYMENT  SITE  1 

1 

1 

1 

1 

1 

•  SHAKEDOWN 

1  -  USER  PARTICIPATION 

1 

-  USER  PARTICIPATION 

1  1 

1 

1 

1 

-TEMP 

1 

1  -TEMP 

1 

•  -TEMP 

1 

•  DEPLOYMENT  * 

1  DEVELOPED 

1 

1 

1  REVISED 

I 

1 

1  REVISED 

1 

1 

1  DECISION  1 

!  T  1 

1  1  1 

1 

1 

1 

-  DT&E - 

1 

1  II  1 

- - -PAT&E-  —►I 

1  II  1 

1 

1 

-  -  OT&E  - 

L  _  1 

J  FIELD  ^  1 

1 

1 

I 

I 

I 

1  1  SHAKEDOWN  1 

1  1  1 

*  PREDEDESFIEID  SHAKE-DOWN 

p  lO  URL  6.1  at  each  deployment  site. 


IMPLEMENTATION  FLOW  DIAGRAM  FOR  DEVELOPMENT  PHASES 


FIGURE  6.2 
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Test  And  Evaluation  Master  Plan 


Order  1810. IF,  Acquisition  Policy  requires  the  development  of 
Test  and  Evaluation  Master  Plans  <TEMPs) .  The  term  TEMP  replaces 
the  term  Master  Test  Plan  (MTP)  and  contains  the  information 
required  in  FAA  Order  1810. 4B.  This  chapter  provides  a  reference 
for  the  development  and  approval  of  TEMPs.  FAA-STD-024 
stipulates  TEMP  content  and  formats. 

Process  Description 

A  TEMP  is  required  for  all  acquisition  programs  unless  a  waiver 
is  granted  by  the  Test  Policy  Review  Committee  (TPRC) .  The  TEMP 
is  the  top-level  test  and  evaluation  (T&E)  program  document  and 
serves  as  the  key  source  document  for  development  of  lower-level 
test  plans.  TEMPs  are  developed  early  in  the  project  life  cycle, 
immediately  after  KDP-1  approval.  The  TEMP  should  be  approved  by 
the  TPRC  prior  to  the  next  KDP  or  major  contract  award (s) .  For 
each  acquisition  program,  the  FAA  Technical  Center  will  appoint 
an  APMT  who  will  work  with  the  PM  in  conducting  the  T&E  program. 

A  program  directive,  drafted  by  the  test  director  for  joint 
signature  with  the  program  manager,  is  the  vehicle  which 
documents  the  agreement  between  the  PM  and  the  FAA  Technical 
Center.  Information  regarding  FAA  Technical  Center  APMTs  may  be 
obtained  from  the  Engineering,  Test  and  Evaluation  Service  (ACN- 
12)  ,  the  Engineering,  Integration,  and  Operational  Evaluation 
Service  (ACW-1),  or  the  Engineering  Research  and  Development 
Service  (ACD-1) .  The  following  are  the  PMs  methods  for 
developing  and  approving  TEMPs,  and  for  obtaining  T&E  policy 
waivers : 

o  Contacts  ACD-1,  ACN-1,  or  ACW-1  to  arrange  for  an  APMT  as 
soon  as  possible  after  program  initiation.  The  ACN 
organization  assigns  APMTs  for  NAS  automation  programs; 
the  ACW  organization  assigns  APMTs  for  communications, 
navigation,  weather,  and  surveillance  programs;  and  the 
ACD  organization  assigns  APMTs  for  advanced  concepts  and 
technology  programs. 

o  Establishes  a  program  directive  with  the  Office  of 

Acquisition  Support  (ASU)  for  Production  Acceptance  Test 
and  Evaluation  (PAT&E)  activities 


Prepares  the  TEMP.  The  development  of  the  TEMP  should 
begin  about  3  months  after  project  initiation.  The  TEMP 
should  be  approved  by  the  TPRC  prior  to  the  next  KDP  or 
major  contract  award (s).  The  format  and  content  of  the 
TEMP  shall  be  in  accordance  with  Order  1810. IF,  FAA  Order 
1810. 4B,  FAA-STD-024  and  use  T&E  terms  and  definitions  as 
defined  in  NAS— MD— 110.  In  case  of  conflict  or 
inconsistency,  Order  1810. IF  and  Order  1810. 4B  take 
precedence . 

Informally  coordinates  the  TEMP  with  those  who  will  be 
involved  in  the  formal  review  process.  This  will 
facilitate  the  formal  coordination  cycle. 

Prepares  a  clearance  record  for  TEMP  review  that  includes 
the  following  organizations:  ARD/ANA/AHN/ANR/ANC/ANW/ 
AND-30/AAP/ANS-200/AOS#,  ASM,  ASU,  ASE-1,  ANS,  ACN/ACD/ 
ACW,  ATR,  AFS,  ATQ-1**,  AND-6*,  AND-3,  AFE***,  (Airway 
Facilities  Division,  Regional  Air  Traffic  Division) **** 

Review  limited  to  projects  within  purview  of  service 
organization 

AND— 6  Point  of  Contact  for  DOD  Representative  on  Joint 
Procurements  only 

MAs  and  subsystems  designated  for  lOT&E  Oversight  only 
For  ANS-200  projects  only 

Review  of  FAA  TEMP  required  by  all  potential  "Field  Test 
Site"  locations'  regional  Airway  Facilities  Division  and 
Regional  Air  Traffic  Division 

Sends  information  copies  of  TPRC  approved  TEMP  to: 

Airway  Facilities  Division,  Regional  Air  Traffic 
Division,  AML-1,  ACT,  AMA-1,  and  ATH 

Includes  a  note  on  the  clearance  record,  in  the  box 
labeled  "REASON  FOR  ATTACHED,"  which  reads,  "RETURN  ALL 
COMMENTS  TO  THE  PROGRAM  MANAGER  FOR  AGTION  AND  TO  ASE-600 
FOR  INFORMATION".  Also  include  a  "DEADLINE  DATE" 
allowing  at  least  3  weeks  for  review. 

Submits  the  clearance  record  and  a  copy  of  the  TEMP  to 
ASE— 600  for  initialing  prior  to  distribution.  After  the 
clearance  record  is  initialed,  it  is  to  be  signed  out  by 
the  director  of  the  project  office. 

Submits  clearance  record  and  copy  of  TEMP  to  ASE-600  for 
review  and  initialing  prior  to  distribution 


Obtains  signature  of  Program  Director  or  Division  Manager 
on  clearance  record 


Reproduces  enough  copies  of  the  clearance  record  and  TEMP 
to  distribute  to  all  TEMP  review  organizations,  and  as 
information  copies 

Distributes  the  clearance  record  and  TEMP  for  review 

Works  off  all  nonconcurs  and  addresses  all  comments  from 
concur  with  comment  responses 

Updates  the  document  incorporating  all  comments  and 
responses  as  appropriate,  and  provides  a  copy  of  the 
updated  TEMP  to  the  APMT 

Arranges  for  the  TEMP  to  be  placed  on  the  TPRC  agenda  by 
contacting  ASE-600 

Prepares  a  disposition  of  all  comments.  This  disposition 
includes  information  on  the  commenting  organization,  the 
comment,  how  it  has  been  accommodated,  or  why  it  has  not 
been  accommodated. 

Prepares  a  presentation  for  the  TPRC  that  provides  the 
following  information  for  T&E  documents: 

Overview  of  the  TEMP  that  addresses  the  following  topics: 

a.  MNS  of  the  program 

b.  Current  NAS  system  capability  (as  applicable) 

c.  Planned  program  capabilities 

d.  NAS  iteroperable  subsystems  configuration  diagram 

e.  General  Test  Overview 

Summarize  T&E  (DT&E/OT&E)  results  to  date 
Describe  T&E  (DT&E/OT&E)  for  the  present  program 
T&E  phase 

List  responsible  test  organizations  for  current 
T&E  phase 

Describe  operational  software  development 
relative  to  the  subsystem  operating  in  the  NAS 
-  Identify  those  programs  not  available  for 
integration  testing  because  of  acquisition 
considerations 

Describe  the  program  methodology  for 
implementation  of  deferred  requirements 
Identify  transitional  interfaces  required  to 
allow  interfacing  to  the  existing  NAS 


Identify  T&E  issues/concerns 


f.  Test  Schedule  Overview 

T&E  schedule  durations 

Major  program  milestones 

Future  T&E  phase  revision  to  the  TEMP 

g.  TEMP  Issues 

-  Provide  a  list  of  reviewers  and  summary  of  all 
comments  received  with  emphasis  on  comments  not 
incorporated  into  the  TEMP  with  supporting 
rationale 

-  TEMP  recommendation  for  approval  by  the  TPRC 
Overview  of  policy  waiver  request  that  addresses: 

a.  Specific  identification  of  waiver  or  deviation  from 
the  T&E  policy  requested 

b.  Rationale  to  support  waiver/deviation  request 

c.  Disposition  summary  of  all  comments  received 

d.  Impact  if  waiver/deviation  request  is  not  approved 
Changes  to  TPRC— Approved  TEMP  in  briefing  that  address: 

a.  Description  of  the  change (s) 

b.  Statement  as  to  why  the  changes  are  necessary 

c.  Disposition  summary  of  all  comments  received 

d.  Indication  that  all  comments  received  have  been 
resolved,  or  an  explanation  as  to  why  the  comment (s) 
cannot  be  accommodated 

o  Provides  the  TPRC  secretariat  with  30  copies  of  the 

updated  TEMP  and  TPRC  briefing  package  at  least  3  weeks 
prior  to  the  scheduled  TPRC  meeting  date;  ASE-600  will 
distribute  with  the  meeting  agenda  to  the  TPRC  members  2 
weeks  prior  to  the  meeting  date 

Lessons  Learned 

FAA  TEMPS  must  be  developed  early  in  the  project  life  cycle  to 
ensure  that  adequate  budget  and  schedule  time  is  programmed  to 
conduct  a  comprehensive  T&E  program.  Late  attention  to  the  T&E 
program  has  generally  resulted  in  program  overruns,  as  well  as 
compressed  and  unrealistic  testing  schedules  with  subsequent 
delays  in  project  deployment. 


Responsibilities 

The  PM  is  responsible  for  ensuring  that  the  intent  of  Order 
1810. 4B,  NAS  Test  and  Evaluation  Program,  is  met. 

ASE-600  is  responsible  for  revising  and  maintaining  FAA-STD-024 
which  describes  content  and  format  requirements  for  an  FAA  TEMP. 

ASE-600  also  serves  as  TPRC  secretariat.  The  following  are  the 
secretariat's  responsibilities: 

o  Assists  the  TPRC  chairperson  with  the  conduct  of  the  TPRC 
meetings 

o  Presents  TPRC  minutes  to  the  committee  for  approval 
o  Tracks  TPRC  action  items 

o  Establishes  the  TPRC  agenda 

o  Maintains  TPRC  records  and  minutes 

o  Coordinates  the  preparation,  distribution,  and  review  of 
all  TPRC  documentation 

Review  and  Approval 

TEMPS  are  reviewed  by  the  TPRC  member  organizations  and  approved 
by  the  TPRC.  The  PM  is  responsible  for  forwarding  approved 
copies  of  the  TEMP  to  interested  organizations  concurrent  with 
distribution  to  the  TPRC. 

Contacts 

The  following  groups  can  be  contacted  for  additional  information 

on  TEMPS : 

o  Engineering  Specialties  and  Configuration  Management 

Division,  ASE— 600,  202—287—8649 

o  ACW-1,  609-484-5016 

o  ACN-1,  609-484-6011 

o  ACD-1,  609-484-6085 
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Reference  Documents 


The  following  documents  are  the  basis  for  the  guidelines 
presented: 

o  Order  1810. IF,  Acquisition  Policy 

o  Order  1810, 4B,  NAS  Test  and  Evaluation  Program 

o  FAA-STD-024,  Preparation  of  T&E  Documentation 

o  NAS-MD-110,  T&E  Terms  and  Definitions  for  NAS 

Point  of  Contact  for  Chapter  7  is  Rebecca  Taylor,  ASE— 600, 
202-287-8649. 
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Chapter  8 


Independent  Operational ' Test 
And  Eva luat ion  Oversight 


This  chapter  provides  a  reference  for  meeting  the  requirements  of 
Order  1810.2,  Independent  Operational  Test  and  Evaluation  for 
Major  Systems  Acquisition,  and  subsystems  designated  for 
oversight . 

Order  1810.2  will  soon  be  revised  to  reflect  several  recent 
acquisition  and  oversight  policy  changes  set  forth  by  the 
Administrator.  In  the  meantime,  both  Order  1810. IF,  FAA 
Acquisition  Policy,  and  Order  1810. 4B,  NAS  Test  and  Evaluation 
Program,  further  define  and  identify  the  role  of  lOT&E  Oversight 
in  the  acquisition  process.  Currently,  the  lOT&E  Oversight 
function  is  applied  primarily  to  Level  I  Major  Acquisition 
Programs,  such  as  AAS,  VSCS,  CWP,  TDWR,  ARSR-4,  Mode-S,  and  MLS. 
However,  recent  FAA  policy  changes  and  planned  increases  in  lOT&E 
support,  will  permit  the  FAA  to  conduct  more  formal  and  indepth 
independent  assessments  of  the  operational  effectiveness  and 
suitability  of  a  substantially  greater  number  of  Level  I,  Level 
II,  and  Level  III  major  acquisition  programs. 

Mission 

The  Office  of  Independent  Operational  Test  and  Evaluation 
Oversight  is  responsible  for  the  objective,  independent 
assessment  of  operational  effectiveness  and  suitability  for  all 
acquisition  programs  designated  by  DOT  or  FAA  Acquisition 
Executive  for  Independent  Operational  Test  and  Evaluation  (lOT&E) 
Oversight.  The  Director,  ATQ-1,  shall  report  lOT&E  findings  to 
the  Administrator  and  the  ARC  prior  to  each  key  decision  point  in 
the  acquisition  program,  and  prior  to  system  commissioning  (ORD) 
at  the  discretion  of  the  Administrator.  The  TEMP  and  each  update 
are  co-approved  and  signed  by  both  the  Director  of  the  Office  of 
lOT&E  Oversight,  and  the  TPRC  Chairperson  for  all  acquisition 
programs  designated  for  lOT&E  oversight.  The  lOT&E  standard  for 
assessing  the  operational  readiness  of  major  acquisitions  to  meet 
FAA  mission  needs,  and  to  be  deployed  in  the  NAS  comprises  the 
following  two  components: 

Operational  Effectiveness:  The  degree  of  overall  mission 
accomplishment  of  a  system  used  by  representative 
operational  personnel.  This  is  accomplished  within  the 
context  of  the  organization,  mission,  and  environment 


o 


anticipated  for  the  planned  operational  employment  of  the 
system. 

o  Operational  Suitability:  The  ability  of  a  system  to  be 
satisfactorily  integrated  and  employed  for  field  use. 
Considerations  are  given  to  operability  by  field 
personnel,  system  compatibility,  reliability,  human 
performance,  maintenance  and  logistic  support,  safety, 
and  training  requirements 

Lessons  Learned 

Operational  testing  schedules  must  not  be  compressed.  Time 
should  be  allotted  in  the  testing  schedule  to  allow  for  fixes  and 
retesting.  The  danger  is  that  while  development  problems  may  be 
solved,  operational  issues  may  not.  The  end  result  could  be  an 
acquisition  product  that  meets  all  specification  requirements, 
but  cannot  be  used  satisfactorily  by  operational  personnel. 

Responsibilities 

The  following  are  the  responsibilities  of  the  lOT&E  Oversight 
Office  which  operates  independently  of  any  PM  or  Program  Sponsor: 

o  Initiate  and  conduct  an  objective,  independent  assessment 
of  operational  effectiveness  and  suitability  for  all 
acquisition  programs  designated  by  the  DOT  or  FAA 
Acquisition  Executive  for  lOT&E  Oversight 

o  Prepare  independent  assessment  oversight  reports  for  the 
Administrator,  the  Acquisition  Executive,  and  ARC 

o  Report  results  and  make  recommendations  to  the 

Acquisition  Review  Committee  at  all  KDPs,  with  regards  to 
operational  effectiveness  and  suitability  for  all 
acquisition  programs  designated  for  lOT&E  oversight 

o  To  ensure  that  they  are  represented  on  the  Acquisition 
Review  Committee  by  the  Director 

o  Review  and  co— approve,  with  the  TPRC  Chairperson,  all 
TEMPS,  and  each  update  for  those  acquisition  programs 
designated  for  lOT&E  oversight 

o  To  obtain  representation  on  the  TPRC  through  the  Director 

o  Provide  appropriate  comments  and  recommendations  to  the 
PM  of  these  acquisition  programs  designated  for  lOT&E 
oversight,  prior  to  each  KDP 


o 


Review,  test,  and  evaluation  requirements,  plans, 
procedures,  and  resources  to  ensure  that  test  and 
evaluation  objectives  are  adequately  addressed  in  support 
of  assessment  of  the  acquisition  system's  operational 
effectiveness  and  suitability 

o  Monitor  the  conduct  of  both  contractor  and  FAA  testing, 
and  review  the  test  results  to  ascertain  system 
effectiveness  and  suitability.  May,  at  the  discretion  of 
the  Director  of  lOTLE,  conduct  independent  testing  and 
analysis  of  test  data. 

o  Determine  the  Critical  Operational  Issues  (COI)  and  the 
Key  Measures  of  Operational  Readiness  (KMOR)  required  to 
support  the  objective  and  independent  assessment  of  the 
operational  effectiveness  and  suitability  of  those 
acquisition  programs  designated  for  lOTLE  Oversight 

o  Represent  the  FAA  on  matters  pertaining  to  lOT&E 

functions  when  responding  to  requests  from  Congress,  the 
Government  Accounting  Office  (GAO) ,  Department  of 
Transportation  (DOT) ,  Office  of  Management  and  Budget 
(0MB),  other  Government  agencies  (e.g..  National 
Aeronautics  and  Space  Administration  (NASA)  or  the 
Department  of  Defense  (DOD) ) ,  industry  and  aviation  or 
national  airspace  user  organizations 

Program  Manager' s  Responsibilities 

o  Support  the  OT&E  function 

o  Approves  testing  reports  prepared  jointly  by  the  APMT  and 
the  Test  Director  (see  Chapter  7),  who  also  establish  the 
"realistic"  test  environment,  conduct  all  testing 
activities 

o  Coordinate  the  TEMP  with  the  lOT&E  office  and  the  program 
sponsor,  and  secure  concurrence  from  both  through  the 
TPRC 

o  Provide  testing  reports  to  the  lOT&E  office  and  the 
program  sponsor 

o  Monitor  the  acquisition  program  to  determine  that  the 
sponsor's  requirements  are  being  met 

0  Prepare  evaluation  criteria  to  assess  the  operational 

acceptability  of  a  major  system.  These  criteria  must  be 
determined  early  in  the  acquisition  cycle  and  made 
available  to  the  PM  and  the  lOTLE  office. 


o  Monitor  operational  testing  and  comment  on  the  APMT'S 
test  report,  or  the  lOT&E  assessment  report 

o  Provide  operational  testing  personnel  with  necessary 
skills  and  training  to  support  the  establishment  of  a 
"realistic"  test  environment 

o  Coordinate  with  PMs,  regions,  the  Office  of  Training  and 
Higher  Education,  and  the  FAA  Academy  to  obtain  trained 
personnel  prior  to  beginning  operational  testing 

o  Coordinate  with  the  regions  to  develop  training 

requirements  for  effective  use  of  the  acquisition  product 


Contacts 

The  following  staff  may  be  contacted  for  additional  information 

on  lOT&E : 

o  lOT&E  Office,  ATQ-1,  FTS  267-8926 

Reference  Dociiments 

The  following  documents  are  the  basis  for  the  guidelines 
presented: 

o  0MB  Circular  A— 109,  Major  Systems  Acquisition 

o  DOT  Transportation  Acquisition  Manual  Chapter  34, 

Appendix  A,  Major  Acquisition  Policies  and  Procedures 

o  Order  1810. IF,  FAA  Acquisition  Policy 

o  Order  1810.2,  Independent  Operational  Test  and  Evaluation 
for  Major  Systems  Acquisition 

o  Order  1810. 4B,  NAS  Test  and  Evaluation  Program 

o  NAS-MD-110,  T&E  Terms  and  Definitions  for  NAS 


Point  of  Contact  for  Chapter  8  is  Charles  Overbey,  ATQ-1, 
FTS  482-6171. 


Chapter  9 


Hiiman  Factors  Engineering 


This  chapter  describes  processes  and  procedures  to  ensure  that 
the  people  who  operate  and  maintain  the  NAS  are  fully  considered 
in  all  phases  of  system  development.  Failure  to  adequately 
include  the  performance  of  the  operator/maintainer  components  of 
systems  increases  the  risk  of  system  malfunction  or  failure.  On 
the  other  hand,  by  understanding,  measuring,  designing,  and 
documenting  for  the  end  user;  system  performance  can  be  enhanced 
for  mission  accomplishment,  safety,  and  supportability .  Both  the 
Capital  Investment  Plan  (CIP)  and  the  Research,  Engineering  and 
Development  {R, E&D)  Plan  emphasize  the  need  for  ensuring  that 
automation  and  the  application  of  technology  to  aviation  take 
full  account  of  the  human  element  in  the  system. 

Definitions 

Human  Factors  (HF)  -  A  multi-disciplinary  effort  to  generate  and 
compile  information  about  human  capabilities  and  limitations;  and 
apply  that  information  to  equipment,  systems,  facilities, 
procedures,  jobs,  environments,  training,  staffing,  and  personnel 
management  for  safe,  comfortable,  effective  human  performance 

Human  Factors  Engineer  -  An  individual  with  specialized  expertise 
in  human  performance  as  well  as  in  systems  engineering  and  the 
acquisition  process 

Human  Factors  Engineering  (HFE)  ~  The  application  of  human 
factors  considerations  concurrent  with  other  engineering 
disciplines  during  the  design,  development,  and  fielding  of  a 
system  in  which  human  performance  is  essential  in  meeting  system 
safety  and  performance  objectives 

HFE  Process  Description 

Practicing  human  factors  engineers  deal  with  a  wide  variety  of 
design  issues  involving  the  functional  integration  of  humans  in 
complex  systems.  Practical  solutions  to  these  issues  generally 
require  identification  of  human  performance  information; 
translating  the  information  into  a  form  germane  to  the  issue;  and 
effectively  communicating  design  trade  offs. 

More  specifically,  the  human  factors  engineer  supports  the 
program  manager  in  meeting  the  customer/user  operational 
performance  requirements  within  program  cost  and  schedule 
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objectives.  The  application  of  human  factors  engineering 
originates  early  in  the  acquisition  decision-making  process 
(starting  with  the  Mission  Analysis  and  continuing  throughout  the 
program)  to  ensure  that  decisions  and  alternatives  regarding 
program  requirements,  solicitation  preparation,  source  selection, 
research,  design,  development,  test,  and  evaluation  are  in 
consonance  with  the  operational  and  maintenance  concept,  suitable 
to  the  intended  operating  environment,  compatible  with  the  user, 
and  meet  the  sponsor's  operational  needs. 

Hiim  Factors  Plan  Description 

To  ensure  human  factors  considerations  are  fully  incorporated  in 
the  system  development,  the  Program  Manager  initiates  a  Human 
Factors  Plan  (HFP)  that  addresses  the  human  performance  and  human 
resource  parameters  for  program  and  design  alternatives.  The  HFP 
is  first  developed  during  Phase  1  and  updated  during  each 
subsequent  acquisition  phase.  The  initial  HFP  outlines  the 
background,  issues,  tasks,  and  strategy  associated  with  human 
considerations  in  the  operation,  maintenance,  and  support  of 
system  options.  Subsequent  updates  to  the  HFP  further  define  and 
refine  the  human  factors  program  and  issues  in  the  program.  The 
HFP  is  a  living  document,  tailored  to  the  specific  program 
requirements,  procurement  strategy,  key  decision  point,  and 
acquisition  phase  as  well  as  customer  considerations  of  the 
program.  It  imposes  only  the  necessary  and  reasonable 
requirements  to  achieve  1)  the  objective  effectiveness  of  human 
performance  during  system  operation,  maintenance,  and  support, 
and  2)  the  efficient  use  of  personnel  resources,  skills, 
training,  and  funds.  The  intent  of  the  HFP  is  to  specify  how  the 
Government  will  direct  and  control  the  identification  and 
resolution  of  human  performance  issues,  so  as  to  integrate  human 
performance  considerations  throughout  the  program.  The  content 
of  a  Human  Factors  Plan  includes: 

1.  Background: 

a.  Program  Summary.  Provides  a  brief  description  of  the 
program  (including  relevant  concepts  for  operation  and 
maintenance) . 

b.  Program  Schedule.  Provides  an  overview  of  the  program 
schedule . 

c.  Target  Audience.  Identifies  the  population  that  will  be 
affected  during  the  operations  and  maintenance  of  the 
system.  Includes  a  description  of  any  relevant 
demographics,  biographical  information,  training 
background,  aptitudes,  anthropometric  data,  physical 
qualifications,  organizational  relationships,  and 
workspace  requirements.  (Lengthy  descriptions  may  be 
included  in  an  appendix) . 


d.  Guidance.  Summarizes  any  decisions,  previous  guidance, 
and  assumptions  that  will  impact  the  human  factors 
approach  or  results. 

e.  Constraints.  Identifies  the  known  or  anticipated  program 
limitations  for  the  system  {e.g.,  technical,  manpower, 
training  time  available,  resources)  that  will  impact  upon 
the  achievement  of  human  performance,  personnel 
resources,  training,  and  human  factors  engineering  goals 
and  requirements. 

2.  Issues  and  Enhancements:  Lists  and  describes  the  problems, 
concerns,  deficiencies,  risks,  and  opportunities  to  be  addressed 
by  human  factors  efforts  during  the  system  development.  (As  this 
list  and  description  of  issues  become  more  lengthy,  the  details 
may  be  included  in  an  appendix) . 

a.  Issue  Description.  Describes  the  issue  or  problem 
background,  importance,  and  consequence. 

b.  Objectives.  Identifies  the  objectives  to  be  met, 
obstacles  to  be  overcome,  and  the  planned  solution. 

Also,  provides  quantifiable  performance  measures  and 
criteria  that  will  be  used  to  evaluate  resolution  of  the 
issue . 

c.  Actions.  Identifies  the  actions  to  be  taken  in 
remediation  of  the  issue  and  current  status. 

3.  Activities:  Provides  a  list  and  description  of  each  activity 
(e.g.,  tasks,  studies,  analyses)  to  be  performed  during  the 
acquisition  in  support  of  resolving  the  issues  and  controlling 
the  human  factors  program. 

a.  Activity  Description.  For  each  phase,  describes  the 
activities  to  be  performed;  the  rationale  (i.e.,  reasons 
for  the  activity  to  be  conducted) ;  the  technical 
information  needed,  data  requirements  and  sources;  the 
estimated  resources  (e.g.,  time,  personnel,  funding) 
required  to  complete  the  activity;  and  the  organization 
expected  to  perform  the  activity. 

b.  Activity  Schedule:  Displays  the  activities  to  be 
undertaken  and  their  relationship  to  each  other  and  to 
other  significant  program  activities,  events,  and 
decision  points. 


4.  Strategy: 


a.  Goals  and  Requirements.  Identifies  the  major  human 
factors  performance  objectives  necessary  to  achieve 
compatibility  and  suitability  with  the  operational  and 
maintenance  concepts. 

b.  Approach.  Describes  the  general  approach  to  be  taken  in 
order  to  achieve  the  human  factors  goals  and 

requirements,  meet  customer  operational  needs,  and 
resolve  major  issues. 

c.  References.  Identifies  relevant  references  needed  for 
the  full  understanding  of  the  HFP . 

Review,  Approval,  and  Distribution 

The  Program  Manager  coordinates  with  (and  provides  copies  to)  the 
matrix  team,  program  sponsor,  and  other  appropriate 
organizations . 

Responsibilities 

o  The  PM  assesses  and  reports  HFE  progress  at  program 
reviews  and  Key  Decision  Points,  and  administers  the 
appropriate  HFE  resources  to  assure  maximum  operational 
effectiveness  is  met 

o  The  program  sponsor  assists  in  assuring  program  HFE 

progress  consistent  with  user  needs  within  the  intended 
operational  environment 

o  Development  program  directors  and  service  directors  (as 
applicable)  ensure  HFE  considerations  are  appropriately 
addressed  at  program  reviews  and  Key  Decision  Points 

o  AXD-4  provides  a  focal  point  for  human  factors 
information  and  support 

o  ASE  provides  technical  support  for  hardware  and  software 
interface  issues 

Lessons  Learned 

HFE  Complexity:  Human  factors  engineering  encompasses  more  than 
providing  evaluations  or  design  guidance  with  respect  to  simple 
controls/lcnobs/dials .  HFE  support  in  system  design  and 
development  also  includes  developing  and  applying  information 
about  the  total  human  performance  envelope  (e.g.  physical  and 
cognitive  workload;  vigilance  tasks;  physiological, 
anthropometric,  and  demographic  concerns)  in  hardware,  software, 
and  procedures  design. 


Early  Participation:  HFE  personnel  must  be  a  part  of  the  program 
team  from  the  very  beginning.  This  early  involvement  will 
identify  and  resolve  performance  deficiencies  up  front  and  help 
reduce  program  cost  and  schedule  risks. 

Avoid  Program  Pitfalls:  Experience  has  shown  that  ignoring  HE 
issues  can  result  in  schedule  and  cost  penalties.  Operational 
systems  flawed  by  the  lack  of  human  factors  will  cost  additional 
resources  as  a  result  of  hardware  modifications,  overly  complex 
procedures  and  regulation,  or  additional  training  to  counter 
(while  not  necessarily  correcting)  the  flaws.  Flawed  systems  may 
cause  unacceptable  technical  or  safety  risks  including 
potentially  fatal  errors. 

Continuity  of  Effort:  The  successful  application  of  human 
factors  to  an  acquisition  program  depends  upon  the  degree  to 
which  there  is  consistent  and  coordinated  incorporation  of  human 
performance  considerations  at  (and  between)  each  step  of  the 
system  development.  This  approach  requires  that  human  factors 
(i.e.,  constraints,  objectives,  requirements,  strategies, 
activities,  standards,  and  specifications)  be  continuously 
addressed  and  updated  during  requirements  determination, 
solicitation  preparation,  source  selection,  design  and  program 
reviews,  and  test  and  evaluation. 

Contacts 

Additional  information  concerning  human  factor  engineering  can  be 
obtained  from: 

o  AXD-4,  202-267-7125 

Reference  Documentation 

The  following  documents  provide  additional  information  about 
applying  human  factors : 

o  FAA  Order  9550.8,  Human  Factors  Policy 

o  FAA  Order  1810. IF,  Acquisition  Policy  (para  4-9) 

o  MIL-H— 46855,  Human  Engineering  Requirements  for  Military 

Systems,  Equipment,  and  Facilities 

o  MIL— STD— 1472,  Human  Engineering  Design  Criteria  for 

Military  Systems,  Equipment,  and  Facilities 

Point  of  Contact  for  Chapter  9  is  Glen  Hewitt,  AXD-4, 
202-267-7125. 
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Chapter  10 


The  NAILS  Program 


This  chapter  provides  a  clear  and  concise  description  of  the 
National  Airspace  Integrated  Logistics  Support  (NAILS)  Program  as 
delineated  in  Order  1800. 58A,  National  Airspace  Integrated 
Logistics  Support  (NAILS)  Policy,  and  outlines  procedures  for 
program  accomplishment. 

NAILS  Process  Description 

Acquisition  of  a  subsystem  or  equipment  entails  not  only  the 
acquisition  of  hardware  and  software,  but  also  acquisition  of  the 
logistics  resources  required  to  support  the  equipment. 

Supportability  must  be  accorded  the  same  level  of  importance  in 
making  program  management  decisions  as  cost,  schedule,  and 
performance  of  the  equipment. 

The  fundamental  objective  of  a  NAILS  program  is  to  ensure  that 
adequate  logistics  resources  are  available  for  the  appropriate 
maintenance  and  operations  of  an  equipment  when  needed.  The  FAA 
NAILS  Policy  Order  ensures  the  infrastructure  is  in  place  by 
designating  NAILS  matrix  organizations  and  their  associated 
responsibilities . 

Definitions 

National  Airspace  Integrated  Logistics  Support  (NAILS)  - 

A  disciplined  approach  to  plan  and  integrate  support 
considerations  into  design;  acquire  the  necessary  initial  support 
for  the  equipment;  and  identify  life  cycle  support  requirements. 

National  Airspace  Integrated  Logistics  Support  Management  Team 
(NAILSMT)  -  A  management  team  formed  to  plan,  coordinate,  and 
integrate  the  efforts  of  all  concerned  with  equipment  support  to 
ensure  that  logistics  support  requirements  are  identified  and 
satisfied  prior  to  deployment  of  the  equipment. 

Associate  Program  Manager  for  Logistics  (APML)  -  An  integrated 
logistics  support  specialist  responsible  for  ensuring  that  all 
NAILS  requirements  are  identified  and  satisfied  for  each  piece  of 
equipment  in  the  acquisition  process;  R, E4D  program;  and  major 
equipment  modification  program. 


Integrated  Logistics  Support  Plan  (ILSP)  -  A  document  that 
describes  the  integrated  logistics  support  program  requirements, 
tasks,  and  milestones  in  the  equipment  acquisition  process;  R,  E&D 
program  or  major  equipment  modification  program.  The  ILSP  is 
developed  under  direction  of  the  APML  with  input  from  the 
NAILSMT.  The  ILSP  is  an  iterative  document  and  is  updated  as  the 
program  progresses. 

Matrix  Organization 

NAILS  programs  shall  be  organized  in  a  matrix  fashion.  Multiple 
organizations  shall  focus  their  efforts  to  support  the  Program 
Manager  (PM)  for  individual  acquisitions.  NAILS  matrix 
organizations  include:  Mike  Monroney  Aeronautical  Center  (AAC) , 
FAA  Technical  Center  (ACT) ,  Office  of  Training  and  Higher 
Education  (AHT) ,  Office  of  Acquisition  Support  (ASU) ,  System 
Maintenance  Service  (ASM) ,  NAS  Transition  and  Implementation 
Service  (ANS) ,  Air  Traffic  Requirements  Service  (ATR) ,  Office  of 
Air  Traffic  Program  Management  (ATZ) ,  and  lead  or  designated 
regional  Airway  Facilities  Division. 

Coordination 

The  NAS  Transition  and  Implementation  Service  (ANS) ,  under  the 
Associate  Administrator  for  Airway  Facilities  (AAF-1) ,  is 
responsible  for  ensuring  that  NAILS  requirements  are  identified 
and  integrated  into  the  acquisition  process  to  facilitate  total 
life  cycle  support.  The  NAILS  Program  Division,  ANS-400,  is  the 
focal  point  for  NAILS  and  coordinates  interaction  among  the 
matrix  organizations.  An  APML  is  designated  by  ANS— 400  and 
chairs  the  NAILSMT.  The  APML  coordinates  NAILS  matrix 
organizational  efforts  in  order  to  obtain  a  tailored  support 
program  for  each  project.  Each  of  the  matrix  organizations  is 
represented  by  an  element  manager  (EM)  at  the  NAILSMT.  NAILS  EMs 
shall  respond  directly  to  the  requirements  of  the  APML. 

NAILSMT  membership  shall  include  the  APML,  program  office,  and 
additional  personnel  as  required,  NAILS  EMs,  representatives  of 
lead  or  designated  FAA  regional  Airway  Facilities  Division, 
representatives  of  the  FAA  Technical  Center,  as  required,  and 
equipment  contractor  representatives,  when  required. 

NAILS  Elements 

NAILS  elements  are  the  principal  logistics  requirements  that  must 
be  properly  integrated  to  achieve  economical  and  effective 
support  of  an  equipment  throughout  its  life  cycle.  The  EMs  from 
the  matrix  organizations  represent  these  eight  NAILS  elements  as 
explained  below: 

o  Direct-Work  Maintenance  Staffing  -  Direct  person-hours 
required  to  maintain  an  equipment  over  its  life  cycle 
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o  Maintenance  Planning  -  The  process  of  determining  and 

establishing  maintenance  requirements  for  the  life  of  a 
supported  equipment.  This  includes  support  for  hardware 
and  software. 

o  Maintenance  Support  Facilities  “  Maintenance  support  work 
areas,  storage  areas  or  other  facilities  required  to 
perform  maintenance  tasks 

o  Packaging,  Handling,  Storage,  and  Transportation  - 

Resources  and  methods  used  to  ensure  that  equipment  and 
support  items  are  preserved,  packaged,  handled,  stored, 
and  transported  safely 

o  Supply  Support  -  Actions  taken  to  acquire,  catalog, 
receive,  store,  and  issue  items  of  supply 

o  Support  Equipment  -  Special  tools  and  equipment  required 
to  support  the  operation  and  maintenance  of  an  equipment. 
This  includes  standard  test  equipment. 

o  Technical  Data  -  Recorded  information  such  as  manuals, 

specifications,  drawings,  and  operational  test  procedures 
required  to  operate  and  maintain  an  equipment  over  its 
life  cycle 

O  Training,  Training  Support,  and  Personnel  Skills  - 

Identification  of  skills,  processes,  procedures,  course 
material,  and  equipment  used  to  train  personnel  to 
operate  and  maintain  an  equipment 

Procedures  for  NAILS  Prc^ram  Accomplishment 

Scheduling  of  tasks  shall  be  compatible  with  the  acquisition 
process  milestones  and  follow  on  logistics  support  requirements. 
These  tasks  shall  be  executed  by  the  NAILS  matrix  organizations 
to  implement  the  NAILS  program  as  follows : 

o  At  program  inception,  the  PM  notifies  ANS— 400  of  the 

proposed  equipment  acquisition  and  requests  that  an  APML 
be  assigned 

o  ANS-400  assigns  an  APML  within  30  days  of  request.  ANS- 
400  then  notifies  the  PM  and  NAILS  matrix  organizations 
of  the  APML  assignment. 

o  The  APML  assists  the  PM  in  the  development  of  budget 

estimates  for  the  acquisition  and  support  costs  related 
to  NAILS  requirements 
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o 


The  APML  develops  an  initial  ILSP  based  on  the 
maintenance,  training,  and  other  logistics  support 
requirements  identified  by  the  NAILS  EMs .  As  the  program 
progresses,  the  APML  updates  the  ILSP  to  reflect  any 
changes.  The  PM  reviews  and  approves  the  ILSP. 

Throughout  the  acquisition  process,  the  APML  acts  as  the  liaison 
between  the  PM  and  the  NAILSMT.  First,  the  APML  ensures  that  all 
NAILS  element  requirements  are  included  in  the  procurement 
package.  Second,  the  APML  monitors  the  procurement  package  and 
coordinates  with  the  PM  and  contracting  offices  to  define  and 
resolve  issues  related  to  NAILS  requirements.  Third,  contract 
data  requirements  list  reviews  and  other  items  of  NAILS  interest 
(such  as  NAS  Change  Proposals  and  Engineering  Change  Proposals) 
are  evaluated  for  completeness,  accuracy,  and  timeliness. 

Contacts 

The  following  offices  can  be  contacted  for  additional  information 
on  NAILS  requirements: 

o  NAILS  Program  Division,  ANS-400,  202-267-7795 
o  NAILS  Policy  and  Planning  Branch,  ANS— 410,  202—267—7926 
o  NAILS  Implementation  Branch,  ANS-420,  202-267-7796 

Lessons  Learned 

Early  identification  of  logistics  support  requirements  and 
associated  support  costs  can  considerably  reduce  problems  during 
system  life  cycle,  and  total  support  at  the  least  life  cycle 
cost . 

The  PM  should  have  a  clear  idea  of  the  basic  function  of  the 
system  being  supported,  and  of  the  support  policy,  before 
preparing  a  detailed  estimate  of  logistics  costs. 

Detailed  documentation  of  NAILS  requirements  in  the  ILSP  saves 
considerable  rewriting  of  the  procurement  package. 

The  NAILS  EMs  should  tailor  logistics  support  analysis 
requirements  carefully  to  avoid  procurement  of  data  and 
deliverables  that  the  program  will  never  use  or  even  be  able  to 
review . 
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Reference  DocTiments 


These  documents  provided  the  basis  for  the  guidelines  presented: 

o  MIL-STD-1388-1A,  Logistics  Support  Analysis 

o  MIL-STD-1388~2A/2B,  DOD  Requirements  for  Logistics 

Support  Analysis  Record 

o  MIL-STD-1561B^  Provisioning  Procedures 

o  FAA-G-1210d,  Provisioning  Technical  Documentation 

o  FAA-G-1375C,  Spare  Parts— Peculiar  for  Electronic, 

Electrical,  and  Mechanical  Equipment 

o  Order  1800. 58A  (Draft),  National  Airspace  Integrated 
Logistics  Support  (NAILS)  Policy 

o  Order  1810.6,  Policy  For  the  Use  of  Nondevelopmental 
Items  (NDI)  in  FAA  Acquisitions 

o  Order  4560. IB,  Policies  and  Procedures  Covering  the 
Provisioning  Process  During  the  Acquisition  of  FAA 
Materiel 

o  Order  6000. 30B,  Policy  for  Maintenance  of  the  National 
Airspace  System  (NAS)  Through  the  Year  2000 

o  Order  6000.38,  Policy  to  Determine  NAS  Equipment  Sparing 
Requirements  for  Airway  Facilities  Work  Center 

o  FAA— STD-035,  Commercial  Equipment,  Market  Research  for 

Point  of  Contact  for  Chapter  10  is  Thomas  Pope,  ANS— 410, 
202-267-7985. 
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Chapter  11 


This  chapter  describes  the  operation  of  the  Procurement  Readiness 
Review  (PRR) . 

PRR  Process  Description 

The  PRR  process  is  designed  to  assist  the  PM  and  other  management 
personnel  in  preparing  the  PR  package.  The  PR  package  includes 
the  specifications,  SOW,  CDRL  and  other  materials  provided  to  the 
CO  with  the  PR  form.  Use  of  the  PRR  Checklist  in  planning  and 
preparing  the  PR  package  will  improve  the  quality  and  consistency 
of  the  PRs  submitted  to  the  Contracting  Office  and  improve 
overall  procurement  efficiency.  The  following  are  included  in 
the  PRR  Checklist : 

o  Program  and  acquisition  documentation 

o  Budget /cost 

o  Schedules 

o  Systems  engineering 

o  Project  Specifications 

o  Test  and  evaluation 

o  Maintenance 

o  Logistics 

o  Risk 

o  Deliverables 

o  Solicitation  provisions 

o  Safety  and  security 

o  Technical  reviews  and  audits 

o  Contractor  performance 

o  Contract  payments 
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Responsibilities 

Responsibilities  for  the  PRR  are  described  in  FAA  Notice  1810.2, 
Procurement  Readiness  Review  (PRR)  Process.  Primary 
responsibility  for  the  PRR  lies  with  PMs  and  program  directors/ 
service  directors. 

The  Program  Manager  is  responsible  for  the  following: 

o  Review  the  PRR  checklist  with  the  program  team  early  in 
the  procurement  planning  cycle  to  identify  and  address 
all  required  items 

0  Periodically  review  the  tailored  PRR  checklist  for  the 
program  with  responsible  team  members 

o  Prepare  briefings  as  required  for  the  Program  Director 
and  AND  management 

The  program  director/ service  director  is  responsible  for  the 
following: 

o  Monitor  the  conduct  of  the  program  and  provide  assistance 
as  requested  by  the  PMs 

0  Conduct  PRR  prior  to  the  transmission  of  the  PR  package 
to  ASU,  allowing  sufficient  time  for  revisions 

o  Ensure  that  PRR  policy  is  carried  out,  make  local 

modifications,  and  suggest  amendments  to  policy  when 
required 


Contacts 

The  following  staff  can  be  contacted  for  additional  information 
on  the  PRR: 

o  AND-4,  202-267-9080 

Reference  Dociament 

The  following  document  is  the  basis  for  the  guidelines  presented: 

o  FAA  Notice  1810.2,  Procurement  Readiness  Review  (PRR) 

Process  (PRR  checklists  are  included  in  this  Notice) 

Point  of  Contact  for  Chapter  11  is  Kenneth  Ward,  AND-4, 
202-267-9080. 
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Chapter  12 


Interface  Management 


This  chapter  describes  the  management  process  for  Interface 
Requirements  Documents  (IRDs)  ,  Interface  Revisions  (IRs) ,  and 
Interface  Control  Documents  (ICDs) . 

Process  Description 

Systems  Engineering  develops  system  level  interface  requirements 
for  a  large  number  of  organizations  engaged  in  design  and 
acquisition  of  NAS  subsystems  to  ensure  compatibility  of  all  NAS 
subsystem  interfaces.  The  systems  engineering  process  will 
document  interface  requirements  through  the  interface  management 
process  which  involves  the  Interface  Control  Working  Groups 
{ICWGs) .  IRDs,  IRs,  and  ICDs  are  the  three  basic  documents  for 
ensuring  interface  compatibility  and  control. 

The  NAS  Interface  Management  Plan,  DOT/FAA/ES-85/01,  fully 
describes  the  management  process  for  functional  and  physical 
interfaces,  and  provides  general  rules  to  guide  the  development 
of  IRDs,  IRs,  and  ICDs.  It  also  defines  the  roles  and 
responsibilities  of  the  ICWGs. 

Interface  Requirements  Documents 

IRDs  contain  the  functional,  performance,  and  verification 
requirements  for  NAS  subsystem  interfaces.  Format  and  content  of 
the  IRDs  are  developed  in  accordance  with  FAA— STD— 025.  The  IRD 
formalizes,  documents,  controls,  and  imposes  interface  design 
requirements  in  accordance  with  applicable  NAS  interface 
standards  and  NAS-baselined  specifications  such  as  the  NAS  Level 
I  Design  Document  (NAS-DD-lOOO)  and  the  NAS  System  Specification 
(NAS-SS-1000)  . 

In  addition  to  IRDs  for  NAS  subsystem— to— subsystem  interfaces, 
there  are  facility  IRDs.  Facility  IRDs  contain  interface 
requirements  between  the  NAS  subsystem  and  the  host  facility. 
Facility  interfaces  are  hardware  interfaces  resulting  from 
subsystem  designs  requiring  floor  space,  specific  environmental 
control,  an  external  power  source,  and  other  facility  support. 
Facility  IRDs  provide  necessary  subsystem  design  requirements  to 
support  the  installation  design  process.  The  IRDs  are  used  by 
the  facility  design  contractor  as  design  requirements,  and  by  the 
subsystem  contractor  as  "not  to  exceed"  requirements. 


The  ICWGs  that  address  subsystem  IRDs  are  chaired  by  the 
organization  responsible  for  interface  management  (Engineering 
Specialties  and  Configuration  Management  Division,  ASE-600) . 

They  are  composed  of  systems  engineering  personnel  and 
appropriate  project  personnel.  Once  subsystem  IRDs  are  endorsed 
by  the  ICWG,  they  are  signed  by  appropriate  project  offices  and 
the  NAS  Systems  Engineering  Service  (ASE-1) .  IRDs  are  baselined 
by  the  NAS  Configuration  Control  Board  (NAS  CCB) .  Signatures  on 
the  IRD/IR  page  certify  that  the  interface  requirements  are 
technically  correct  and  that  the  signatories  agree  that  the 
requirements  can  be  implemented.  Signing  the  IRD/IR  does  not 
imply  that  funding,  schedule,  pro ject— level  documentation  and 
other  requirements  associated  with  the  interface  are  resolved. 
These  needs  must  be  addressed  by  the  NAS  Change  Proposal  (NCP) , 
and  the  data  attached  to  it.  The  NCP  must  be  approved  by  the  NAS 
CCB.  In  addition,  approval  of  an  NCP  does  not  allocate  funding, 
it  only  assigns  a  cost  for  the  implementation  of  an  engineering 
change.  A  Financial  Baseline  Change  Notice  (FBCN)  must  be 
approved  before  funds  are  allotted  as  part  of  the  financial 
baseline . 

The  ICWGs  that  address  facility  IRDs  are  chaired  by  the 
appropriate  Facility  System  Engineering  Division  (AFE-100/200) 
responsible  for  facility  IRDs.  The  facility  IRDs  are  signed  by 
project  offices  and  appropriate  Facility  Systems  Engineering 
divisions,  and  are  baselined  by  the  NAS  CCB. 

Interface  Control  Documents 

ICDs  specify  the  technical  design  of  an  interface.  Initial 
development  of  ICDs  is  carried  out  by  the  lead  PM.  An  ICD 
documents  how  interface  design  requirements  shall  be  implemented. 
The  major  purpose  of  an  ICD  is  to  ensure  that  interface 
compatibility  is  established  and  maintained.  This  is  done  by 
documenting  the  form,  fit,  and  function  required  to  satisfy 
installation,  checkout,  and  operation.  ICDs  must  be  compliant 
with  the  related  IRDs  and  subsystem  specifications.  ICDs  are 
required  for  all  technical  interface  designs  that  are,  or  would 
normally  be,  controlled  by  IRDs.  This  includes  interfaces  among 
the  NAS  subsystems  and  between  NAS  subsystems  and  external 
subsystems . 

The  ICWGs  that  address  ICDs  are  chaired  by  the  lead  project 
office  and  are  composed  of  project  personnel  from  each  side  of 
the  interface,  and  associated  contractors.  Systems  Engineering 
personnel  may  attend  an  ICD  ICWG  when  there  are  design  issues 
that  relate  to  IRD  requirements.  When  an  ICD  is  endorsed  by  the 
ICWG,  it  is  signed  by  the  appropriate  NAS  project  offices  and  the 
subsystem  contractors.  At  that  point,  the  lead  project  office 
baselines  the  document  at  the  program/project  CCB. 
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The  change  control  process  for  IRDs  and  ICDs  is  governed  by  Order 
1800. 8F,  NAS  Configuration  Management  and  FAA-STD-021, 
Configuration  Management.  Authority  for  IRD/ICD  preparation  and 
revision  is  through  the  use  of  interface  revisions  as  described 
in  FAA-STD-025.  Agreed-upon  revisions  developed  through  the 
interface  management  process  are  then  baselined  through  the 
change  control  process  described  in  Order  1800. 8F. 

No  change  which  affects  interface  compatibility  shall  be 
initiated  in  a  design  without  following  the  appropriate  revision 
and  change  control  process.  This  rule  does  not  apply  to  intra¬ 
subsystem  interfaces  that  do  not  impact  other  subsystems . 

Interface  Revisions  (IRs) 

An  Interface  Revision  is  a  documented  change  to  a  baselined  IRD 
that  is  under  configuration  control.  The  procedure  for  the 
development  of  the  IR  is  the  same  as  it  is  for  the  IRD  except 
that  the  IR  can  occur  anytime  after  an  IRD  is  baselined. 

The  IR,  like  the  IRD,  must  comply  with  NAS-DD-1000  and  NAS-SS- 
1000.  Once  the  IR  is  incorporated  in  a  revision  of  the  IRD,  the 
revised  document  becomes  the  requirements  document  for  the 
interface . 

Figure  12.1  is  a  diagram  of  the  interface  management  process 
structure.  Figure  12.2  is  a  diagram  of  the  IRD/IR  development 
and  approval  process. 

Lessons  Learned 

Attempting  to  resolve  interface  issues  without  coordinating  with 
Systems  Engineering  delays  the  issuance  of  approved  IRDs. 

Technical  interface  requirements  of  the  NAS  are  generally  not 
negotiable  rather,  they  flow  from  NAS-SS-1000  which  ensures 
compatibility  and  performance  of  NAS  technical  interfaces. 

Project  personnel  need  to  have  an  acceptable  ICD  before  their 
contractor  begins  building  the  interface.  It  can  be  costly  and 
may  have  adverse  schedule  impacts  if  changes  are  required  after 
interface  construction  has  begun. 

Due  to  delays  in  the  contracting  process,  it  is  possible  to  have 
different  versions  of  IRDs  on  contract  to  interfacing 
contractors .  It  is  important  all  parties  involved  with  the 
production  of  any  ICD  in  this  situation  work  to  eliminate  any 
problems  this  may  cause  the  contractors. 

Contractors  do  not  realize  the  amount  of  effort  required  to 
draft,  review,  and  finalize  an  Interface  Control  Document  (ICD) . 
Some  contractors  believe  that  providing  preliminary  and  final  ICD 


drafts  are  the  sum  of  their  responsibility.  It  is  recommended 
that  the  Statement  of  Work  (SOW)  should  contain  specific 
paragraphs  that  specify  the  Government's  requirements  for 
contractor  involvement  in  the  generation  of  ICDs.  These 
paragraphs  should  list  obligations  such  as  coordinating  with 
interfacing  contractors,  participation  in  Interface  Control 
Working  Groups  (ICWGs)  and  Technical  Interchange  Meetings  (TIMs) , 
resolving  technical  interface  issues,  and  the  production  of  a 
baselined  version  of  the  ICD.  It  should  be  made  clear  that  these 
responsibilities  continue  until  an  ICD  is  formally  baselined. 
Interface  Management  has  sample  copies  of  a  SCW,  DID,  and  CDRL 
that  discuss  ICDs.  Interface  Management  also  has  a  draft  letter 
for  establishing  ICD  milestones  with  interfacing  subsystems. 
Copies  of  these  documents  are  available  through  Rebecca  Taylor, 
ASE-600,  202-287-8649. 

Responsibilities 

Program  Managers  are  responsible  for  ensuring  that  IRDs  and  ICDs 
are  incorporated  into  acquisition  contracts  as  compliance 
documents . 

ASE-600  is  responsible  for  the  following: 

o  Interface  management 

o  Subsystem  IRDs 

o  Establishment  of  interface  and  network  standards 
o  Definition  of  subsystem  interfaces  in  NAS-SS-1000 
o  Technical  content  of  subsystem-to-subsystem  IRDs 
AFE-100/200/300  are  responsible  for  the  following: 
o  Facility  IRDs 

o  Definition  of  facility  interfaces  in  NAS-SS-1000 

Review  and  Approval 

IRDs  are  reviewed  by  Systems  Engineering  and  subsystem  project 
offices  and  are  approved  by  the  NAS  CCB. 

ICDs  are  reviewed  by  the  subsystem  project  offices  and  approved 
by  the  leading  program/project-level  CCB. 


Contacts 


The  following  divisions  or  groups  can  be  contacted  for  additional 
information  in  the  areas  indicated: 

o  Subsystem  IRD  contacts  are  ASE-600  (202-287-8649)  and 

SEI/SE&D  (202-646-2314) 

o  Facility  IRD  contacts  are  AFE-100  (ARTCC/ACF)  (202-287- 
8580),  AFE-200  (ATCT)  (202-287-8593),  AFE-300  (AFSS) 
(202-287-8584) ,  'and  SEI/SE&D  (ARTCC/ACF)  (202-646-2167) 
or  (ATCT)  (202-646-5774) 

o  NAS  CCB  operation  information  can  be  obtained  from  ASE- 
3.1  (202-287-8655)  or  SEI  (202-646-6972) 

Reference  Dociaments 

The  following  documents  are  the  basis  for  the  guidelines 
presented: 

o  Order  1800. 8F,  NAS  Configuration  Management 

o  FAA-STD-025,  Preparation  of  Interface  Documents 

o  FAA-STD-021,  Configuration  Management  (Contractor 

Requirements ) 

o  DOT/FAA/ES-85/01,  NAS  Interface  Management  Plan 

o  NAS-DD-1000,  NAS  Level  I  Design  Document 

o  NAS-SS-1000,  NAS  System  Specification 

Point  of  Contact  for  Chapter  12  is  Rebecca  Taylor,  ASE-600, 
202-287-8649. 
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INTERFACE  MANAGEMENT  PROCESS  STRUCTURE 


FIGURE  12.1 


12-6 


IRD/IR  DEVELOPMENT  AND  APPROVAL  PROCESS 
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Chapter  13 


This  chapter  describes  configuration  management  for  the  National 
Airspace  System  (NAS) ,  including  the  Specification  Review  Board 
procedures . 

Process  Description 

Configuration  management  (CM) ,  an  integral  part  of  System 
Engineering,  is  the  discipline  used  to  identify  and  document  the 
functional  and  physical  characteristics  of  an  item  during  its 
life  cycle.  Further,  configuration  management  is  used  to  control 
changes  to  those  characteristics,  and  to  record  and  report  change 
processing  and  implementation  status.  Ultimately,  CM  is  a  tool 
for  monitoring  and  controlling  cost  by  providing  visibility  to 
requirements  growth  and  requirements  changes. 

Central  to  CM  is  the  concept  of  baseline  establishment  and 
management.  A  baseline  may  well  be  described  as  a  snapshot  in 
time  of  an  item.  Establishing  a  baseline  initiates  the  formal 
change  control  process.  This  process  ensures  that  all  technical, 
cost,  schedule,  and  interface  aspects  are  considered  before  any 
change  is  approved  and  implemented.  Changes  to  baselines  can  be 
made  only  following  approval  by  a  duly  constituted  CCB . 

Order  1800. 57A  established  the  NAS  CCB.  The  NAS  CCB  in  turn 
established,  through  charters,  subordinate  CCB' s  to  manage  the 
change  control  process  at  the  appropriate  level.  Charters  for 
lower-level  CCBs  and  operating  procedures  for  each  CCB  have  been 
approved  by  the  NAS  CCB.  At  the  acquisition  project  level,  there 
are  program  CCBs  for  each  acquisition  program  within  the  Office 
of  the  Associate  Administrator  for  Airway  Facilities  (AAF) ,  and 
the  Office  of  the  Associate  Administrator  for  NAS  Development 
(AND).  At  the  operational  level,  there  are  regional  CCB's,  an 
Air  Traffic  (AT)  CCB,  and  a  Maintenance  Engineering  (ME)  CCB. 

Configuration  Management  consists  of  configuration 
identification,  configuration  control,  status  accounting,  and 
auditing.  These  functions  are  controlled  and  can  be  performed 
with  the  hardware  and  software  design  specifications,  engineering 
drawings  and  the  system  technical  instruction  boo)c.  Any  system 
can  be  configuration  managed  using  the  latest  revision  of  the 
above  documents . 


Configuration  Identification 

Configuration  identification  is  the  aggregate  of  the  family  of 
technical  documents  including  specifications,  technical 
instruction,  and  drawings  that  describes  the  system  or 
configuration  item  (Cl) . 

NAS-MD-001,  National  Airspace  System  Master  Configuration  Index, 
defines  configuration  identification  for  NAS  subsystems  both 
fielded  and  in  the  acquisition  process.  Only  CIs  that  are 
currently  operational  or  in  acquisition  appear  in  this  listing, 
along  with  the  most  current  revision  of  their  baseline 
documentation.  NCPs  are  required  to  change  or  add  CIs  to  NAS-MD- 
001.  NAS-MD-001  contains  the  entire  hierarchy  of  NAS  CIs  with 
all  baselined  documentation  and  approved  documentation  changes 
for  each  Cl . 

Based  on  the  Level  I  Design  Document,  NAS-DD-1000,  the  Master 
Configuration  Index  shows  parent-child  relationships  among  the 
NAS  subsystems.  This  index  is  updated  with  each  publication  of 
NAS-MD-001.  It  is  part  of  the  computer-based  Documentation  and 
Configuration  Identification  System  (DOCCON)  and  is  available  to 
all  FAA  employees  by  remote  terminal. 

As  part  of  the  configuration  identification,  Orders  1800. 8F  and 
1800. 57A  require  that  certain  NAS-level  documentation  be 
baselined.  Those  documents  are  NAS-SR-1000,  NAS-DD-1000,  and 
NAS-SS-1000 . 

Specification  Review  Board 

This  section  provides  a  reference  to  the  Specification  Review 
Board  (SRB) .  The  SRB  was  established  by  Order  1800.8  for  the 
purpose  of  reviewing  and  endorsing  all  new  specifications,  and 
standards.  The  objective  is  to  ensure  complete  and  consistent 
NAS  baseline  documentation. 

Process  Description 

Prior  to  writing  a  draft  specification  the  program  office  should 
contact  ASE-3.2,  Configuration  Management  for  a  list  of  required 
reviewers  and  to  obtain  basic  information  about  the  review 
process . 

Once  the  draft  specification  or  standard  is  completed,  a 
clearance  record  review  is  done  using  the  list  of  reviewers 
provided  by  ASE-3.2.  The  final  package,  including  the  resolution 
of  comments,  is  delivered  to  ASE-3.2,  who  will  then  organize  and 
schedule  an  SRB  and  transmit  the  package  with  pertinent 
information  to  SRB  participants.  Generally,  ASE-3.2  allows  15  to 
30  days  between  distribution  of  the  package  and  the  scheduled  SRB 
date  to  provide  sufficient  time  for  review.  The  SRB  is  the  forum 
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for  resolving  remaining  issues  and  the  last  opportunity  to  raise 
any  issues  which  have  been  overlooked  in  the  clearance  record 
process.  Program  managers  should  make  a  good-faith  effort  to 
resolve  outstanding  comments  and  non-concurs  prior  to  the  SRB. 

ASE-3.2  chairs  the  SRB  and  prepares  and  transmits  the  minutes. 
Assuming  no  further  actions  or  resolutions  are  required,  the 
specification  is  endorsed  by  the  SRB  and  forwarded  via  a  NAS 
Change  Proposal  (NCP)  to  the  appropriate  Configuration  Control 
Board  (CCB)  for  signature.  The  CCB  Chairperson's  Signature  on 
the  CCD  baselines  the  specification.  For  most  specifications, 
the  appropriate  CCB  will  be  the  sponsoring  program  directorate 
CCB.  Specification  numbers  are  assigned  by  ASE-3.2  following 
endorsement  by  the  SRB. 

The  SRB  process  for  new  standards  is  the  same  as  for 
specifications.  However,  when  a  new  standard  is  endorsed  by  the 
SRB,  it  is  transmitted  via  an  NCP  to  the  NAS  CCB  for  approval . 

Responsibilities 

Program  and  project  office  responsibilities: 

o  Coordinate  with  ASE-3.2  for  list  of  reviewers  and 
tentative  schedule 

o  Prepare  the  draft  specification  document 

o  Coordinate  the  clearance  record  review  of  the  draft 
document 

o  Resolve  reviewers'  comments 

o  Coordinate  date  of  the  SRB  with  ASE-3.2 

o  Provide  copies  of  draft  document  and  resolution  of 
comments  for  SRB 

o  Prepare  the  NCP  following  approval  by  the  SRB 
ASE-3.2' s  responsibilities: 

o  Provide  guidance  on  the  entire  SRB  review  process 
o  Organize  and  coordinate  SRB  activities 

o  Act  as  chairperson  for  SRB  meetings 
o  Provide  secretariat  support 

o  Publish  minutes  of  the  SRB 
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o 


Assign  specification  numbers  to  approved  documents 


SRB  members  attend  the  SRB,  provide  comments,  and  participate  in 
the  resolution  of  comments. 

Lessons  Learned 

Diligently  resolving  all  comments  and  issues  received  during 
clearance  record  review  of  the  document  will  ensure  SRB 
effectiveness  and  save  time.  It  is  important  to  work  closely 
with  program  offices  which  may  be  impacted  by  the  new  project. 

Review  and  Approval 

FAA  specifications  are  reviewed  by  the  SRB.  The  SRB  forwards  a 
recommendation  for  final  approval  to  the  CCB.  The  CCB  approval 
constitutes  final  approval  following  which  the  document  will 
become  a  baseline. 

Configuration  Control 

The  configuration  control  or  change  control  process  is 
essentially  the  same  for  all  baselines  regardless  of  the 
controlling  CCB.  The  general  process  consists  of  the  following 
steps : 

o  Office  proposing  a  change  to  a  baseline  develops  a  case 
file.  A  case  file  can  be  initiated  by  any  FAA 
organization  against  any  NAS  related  Cl.  (See  Appendix  A 
for  a  sample  of  FAA  Form  1800-2) 

o  The  case  file  is  pre-screened  for  completeness  by  the 
organization  responsible  for  that  particular  baseline. 

In  the  event  the  proposed  change  impacts  several 
baselines,  the  controlling  CCB  is  the  CCB  responsible  for 
the  highest  level  baseline  impacted. 

o  If  the  case  file  passes  the  pre-screen  process,  ASE-3.2 
assigns  an  NCP  number  and  sends  it  to  the  appropriate 
reviewers  for  evaluation  and  comment .  Reviewers 
generally  include  those  organizations  that  have  an 
interest  in  or  are  impacted  by  the  proposed  change. 

o  The  NCP  originator  resolves  all  received  comments.  Case 
file  originators  should  take  an  active  role  in  notifying 
reviewers  ahead  of  time  to  let  them  know  that  their 
proposed  change  will  be  coming  their  way. 

o  For  NAS  CCB  meetings,  the  originator  must  supply  ASE-3.2 
with  the  NCP  meeting  package  and  the  briefing  that  will 
be  given  to  the  board  at  least  two  weeks  in  advance. 
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Evidence  that  all  comments  have  been  resolved  must  be 
included.  Each  individual  scheduled  to  appear  before  the 
NAS  CCB  must  present  the  proposed  change  to  a  NAS  pre¬ 
board  held  one  week  earlier. 

o  Preparation  procedures  for  CCB  meetings  other  than  the 
NAS  CCB  vary  somewhat.  NCP  originators  should  consult 
the  operating  procedures  of  the  respective  CCB. 

Configuration  Status  Accounting 

Configuration  status  provides  for  establishing  a  configuration 
baseline,  accounts  for  and  traces  changes,  and  facilitates  the 
implementation  of  changes. 

The  FAA  employs  a  computer-based  configuration  status  and 
accounting  system,  DOCCON,  to  support  the  configuration  status 
function . 

Review  and  Approval 

NCPs  are  reviewed  by  the  appropriate  reviewers  and  approved  by 
the  CCB  responsible  for  the  baseline  document  under 
consideration . 

NCPs  which  impact  more  than  one  baseline  document  are  approved  by 
the  CCB  responsible  for  the  highest  level  baseline  document 
affected . 

Project  Planning 

Since  appropriate  application  of  CM  in  a  project  can  provide  a 
high  degree  of  visibility  into  contractor  performance,  it  is 
important  for  program  managers  to  coordinate  with  ASE-3 . 2  as 
early  as  possible  in  project  planning.  Coordinate  with  ASE-3. 2 
wording  of  CM  requirements  for  the  Request  for  Proposal  (RFP)  and 
for  inclusion  of  the  appropriate  CM  data  items,  such  as  a  CM 
plan,  configuration  status  accounting  data,  and  configuration 
audit  plan. 

ASE-3. 2  participation  in  NAS  Integrated  Logistics  meetings 
(NAILSMTs) ,  technical  interchange  meetings  (TiMs) ,  and  design 
reviews  is  important. 

Configuration  Audits 

Configuration  audits  validate  that  functional  and  performance 
requirements  are  achieved  and  that  product  configuration  is 
verified  by  comparing  the  Cl  with  its  technical  documentation. 
Both  functional  configuration  audits  (FCAs)  and  physical 
configuration  audits  (PCAs)  are  performed. 
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The  FCA  and  PCA  is  normally  held  between  two  key  events  during 
the  acquisition.  The  first  event  is  first  article  testing  at  the 
contractor's  plant,  FAA  Technical  Center,  or  an  FAA  key  site. 

The  second  event  is  the  baselining  of  the  First  Article  at  the 
product  level  within  the  NAS.  All  testing  should  be  completed  on 
a  Cl  before  an  audit  is  conducted. 

The  FCA  determines  whether  the  actual  performance  of  each  Cl 
complies  with  its  controlling  specification.  Particularly,  an 
FCA  must  verify  that  the  functional,  allocated  (if  applicable) , 
and  proposed  product  baselines  are  consistent.  The  FCA  verifies 
that  functional  requirements  are  traceable  from  the  system  level 
specification  (Type  A)  through  the  design  documentation,  test 
documentation  and  to  the  test  results.  The  FCA  can  vary 
according  to  the  type  of  Cl  being  audited.  For  example,  the  FCA 
for  a  complex  Cl  may  be  conducted  on  a  progressive  basis 
throughout  the  Cl's  development.  The  FCA  will  normally  begin  at 
the  completion  of  design  qualification  testing  with  a  review  of 
all  discrepancies  at  the  final  FCA. 

The  PCA  is  a  formal  examination  of  CIs  and  technical 
documentation  to  ensure  a  match  between  the  technical 
documentation  and  the  "as-built"  CIs.  Successful  completion  of 
the  PCA  is  a  prerequisite  to  establishing  the  product  baseline. 
After  PCA,  all  subsequent  changes  to  product  baselines  are 
submitted  to  the  FAA  via  a  Class  I  Engineering  Change  Proposal 
(ECP)  . 

All  audit  activity  must  be  complete  and  approved  before 
establishing  the  product  baseline.  The  contract  must  have  the 
FCA/PCA  included  in  project  milestone  schedules.  If  the  FCA/PCA 
is  not  included  in  project  schedules,  the  program  management 
office,  in  collaboration  with  ASE-3 . 2  and  ASU-300,  must  determine 
the  proper  time  for  FCA/PCA  activity. 

Lessons  Learned 

NCPs  which  do  not  thoroughly  describe  the  problem,  do  not 
adequately  describe  the  proposed  solution,  and  those  lacking 
support  documentation  do  not  receive  proper  review  and  may  need 
to  be  returned  for  rework  thereby  delaying  approval  of  the  change 
proposal . 

It  takes  considerable  time  to  plan  and  conduct  FCAs  and  PCAs  for 
complex  CIs.  Allow  sufficient  time  for  feedback  to  the 
contractor  and  correction  of  any  deficiencies  found  during  the 
audits . 
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Responsibilities 

Program  managers  are  responsible  for  the  following: 

o  To  coordinate  with  ASE-3.2  very  early  in  project 
planning 

o  Ensuring  that  FAA-STD-021  and  other  CM  related  standards 
are  included  in  all  contracts  in  accordance  with  Order 
1800 . 8F 

o  Ensuring  that  contractors  meet  contract  CM  requirements 

o  Ensuring  that  contractor  Engineering  Change  Proposals 
(ECPs) /  Deviations  and  Waivers  are  processed  in 
accordance  with  FAA-STD-021 

o  Establishment  of  appropriate  CM  baselines 

o  Initiating  appropriate  NCPs  to  higher  level  boards  when 
required 

Contacts 

The  following  groups  can  be  contacted  for  additional  information 

in  the  areas  indicated: 

o  Configuration  management  issues,  ASE-3.2,  202-287-8653, 
202-287-8654,  202-287-8657 

o  NAS  CCB  business,  ASE-3.2,  202-287-8653 

o  CM  policy/procedures,  ASE-3.2,  202-287-8653, 
202-287-8654,  202-287-8657 

o  FAA-STD-021,  ASE-3.2,  202-287-8653 

o  DOCCON/CM  tools,  ASE-3.2,  202-287-8654 

o  CM  audits,  ASE-3.2,  202-287-8653,  202-287-8654, 
202-287-8657 

o  Acquisition  CM 

AAP  CM  (AAS) ,  ASE-3.2,  202-287-8654 
AAP  CM  (VSCS) ,  ASE-3.2,  202-287-8654 
AND  CM,  ASE-3.2,  202-287-8653 

o  Air  Traffic,  ASE-3.2,  202-287-8657 
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o  ME  CCB,  ASE-3.2,  202-287-8657 
o  Configuration  Management  Officers  (SEIC) 

AAP-200,  202-646-5353 
AAP-400,  202-646-4855 
ANA,  202-646-6976 
ANC,  202-646-2191 
ANN,  202-646-4851 

ANR,  202-646-5881 

ANS,  202-646-2321 
ANW,  202-646-2321 
ARD,  202-646-2321 
NAS,  202-646-6992 

o  Change  Control  &  Status  Accounting,  202-646-2203 
NAS  CCB,  202-646-6972 

ANF,  ANN,  ANW,  ARD,  AT  CCB,  202-646-2091 
ANA,  ANC,  ANR  CCB,  202-646-5552 
ME  CCB,  202-646-2236 

o  Master  Configuration  Index,  202-646-5492,  202-646-5928 

Reference  Documents 

The  following  documents  are  the  basis  for  the  guidelines 
presented : 

o  Order  1800. 8F,  NAS  Configuration  Management 

o  Order  1800. 57A,  Establishment  of  the  National  Airspace 
System  (NAS)  Configuration  Control  Board 

o  FAA-STD-002,  Preparation  of  Engineering  Drawings 

o  FAA-STD-005,  Preparation  of  Specification  Documents 

o  FAA-STD-021,  Configuration  Management  (Contractor 

Requirements) 
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o  MIL-STD-973,  Configuration  Management,  Paragraph  5.5 
Configuration  Status  Accounting,  &  Paragraph  5.6 
Configuration  Audits 

o  NAS— MD-001,  NAS  Subsystem  Baseline  Configuration  and 

Documentation  Listing 

o  NAS-DD-1000,  NAS  Level  I  Design  Document 

o  NAS-SS-1000,  NAS  System  Specification 

o  NAS-SR-1000,  NAS  System  Requirements  Specification 

o  FAA  Form  1800-2,  NAS  Change  Proposal  (NCP)  Form 

o  CCB  Charters  and  Operating  Procedures  -  Charters  and 

operating  procedures  for  program  CCBs  (acquisitions) , 
regional  CCBs,  the  AT  CCB,  and  the  ME  CCB 

o  Guidance  and  Implementation  Planning  for  the  Conduct  of 
Formal  Configuration  Audits,  Revision  5,  dated  January 
29,  1988  -  Guidelines  published  by  SEIC  for  ASE-3.2  for 
the  planning  and  conducting  of  PCAs  and  FCAs 

o  Configuration  Management  Procurement  Guidance, 

Revision  4,  dated  October  26,  1989  -  Guidelines  published 
by  SEIC  for  ASE-3.2  for  the  application  of  FAA-STD-021  on 
project  acquisition  contracts 


Point  of  Contact  for  Chapter  13  is  Daryl  Wyrick,  ASE-3.2, 
202-287-8654 . 
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Chapter  14 


This  chapter  provides  a  reference  to  the  selection  and 
application  of  standards  and  general  equipment  specifications  for 
NAS  acquisitions. 

Process  Description 

FAA,  military,  and  DOD  standards  and  general  equipment 
specifications  are  documents  that  establish  engineering  and 
technical  requirements  for  processes,  procedures,  practices,  and 
methods  that  have  been  adopted  as  standard.  General  equipment 
specifications  and  standards  are  employed  to  give  programs  the 
benefit  of  previous  experience,  to  promote  commonality,  and  to 
minimize  logistics  costs.  Implementation  of  specific  standards, 
however,  must  be  carefully  considered  to  ensure  that  these 
general  standards  and  specifications  do  not  create  unnecessary 
costs  for  the  program,  that  the  standards  represent  current 
acceptable  technology,  and  that  tiering  is  minimized.  Tiering  is 
the  incorporation  of  standards  due  to  cross-referencing  at 
successively  lower  levels. 

The  development  of  project  specifications  and  statements  of  work 
that  utilize  standards  and  general  equipment  specifications 
requires  the  following  two  steps; 

o  Selection  of  standards  for  application 

o  Application  of  the  standards 

Selection  of  Standards  for  Application 

In  selecting  standards  for  application  to  a  specific  project,  the 
following  documents  should  be  consulted: 

o  NAS-MD-001,  NAS  Subsystem  Baseline  Configuration  and 
Documentation  Listing 

o  NAS-SS-1000,  NAS  System  Specification,  Volume  I, 

Section  2.0,  Applicable  Documents 
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o  Order  1830. 2B,  Telecommunications  Standards  Selection  and 
Implementation  Policy  in  conjunction  with  FAA-STD-029, 
Selection  and  Implementation  of  Telecommunications 
Standards,  and  FAA-STD-039,  NAS  Open  System  Architecture 
and  Protocols 

o  Order  1800. 8F,  NAS  Configuration  Management,  Appendix  3 
(replaces  Order  4405. G,  Specification  Currency  List  for 
Procurement  in  the  Air  Traffic  Control  and  Navigation 
System,  which  is  out  of  date) 

Each  standard  should  be  reviewed  as  to  applicability  to  the 
particular  project  and  tailored  for  use.  For  example,  if  the 
objective  of  the  project  is  to  develop  new  electronic  equipment 
to  provide  the  required  functions,  the  general  specification, 
FAA-G-2100,  Electronic  Equipment,  General  Requirements,  would  be 
selected  and  tailored  for  new  development .  If  the  required 
functions  can  be  provided  by  commercial  off-the-shelf  (COTS)  or 
non-developmental  item  (NDI)  products,  then  FAA-G-2100  must  be 
tailored  for  COTS/NDI .  A  tailoring  guide  for  NDI/COTS  is 
included  in  the  revised  FAA-G-2100F. 

Application  of  Standards 

Before  selected  standards  are  incorporated  into  the  contract, 
they  should  be  tailored.  There  are  a  number  of  appropriate  ways 
to  tailor  standards  or  general  equipment  specifications.  The 
application  of  a  standard  may  be  limited  to  specified  components 
or  types  of  components  within  the  system.  Applicable  portions  of 
a  standard  may  also  be  extracted  for  incorporation  into  the  text 
of  a  project  specification.  In  either  case,  a  referenced 
standard  may  be  supplemented  by  descriptive  text  in  the 
specification  which  clarifies  the  intended  requirements  or 
application.  Inapplicable  portions  of  a  standard  may  be  deleted 
by  identifying  them  in  the  system/equipment  specification  or 
appendix  thereto.  The  following  is  a  specific  tailoring  example: 
FAA-G-2100F,  paragraph  3.3.1.3.4.16.5(e),  specifies  that  terminal 
boards  used  in  interconnecting  units  shall  have  10  percent  extra 
spare  unused  terminals,  but  in  no  case  less  than  two.  A  program 
manager  may  decide  that  the  requirements  of  his/her  particular 
program  need  at  least  four  spare  terminals.  The  program  manager 
may  indicate  this  requirement  in  the  specification  along  with  a 
specific  exemption  to  FAA-G-2100F,  paragraph  3.3.1.3.4.16.5(e). 

Specific  guidance  on  tailoring  software  specifications  may  be 
found  in  Chapter  15,  Software  Acquisition  Management.  Tailoring 
specifications  for  software  acquisitions  is  especially  important 
to  the  later  success  of  the  overall  program.  For  this  reason,  it 
is  treated  in  a  separate  chapter. 
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Where  standards  impose  requirements  for  delivery  of  data  and 
reports  in  contracts,  the  appropriate  contract  data  requirements 
are  to  be  specified  in  the  Contract  Data  Requirements  List 
(CDRL) .  The  CDRL  items  should  specify  the  appropriate  data  item 
descriptions  that  have  been  tailored  in  Block  16  of  the  CDRL  form 
to  delete  inapplicable  requirements. 

Configuration  management  should  start  in  the  requirements  phase. 
This  will  ensure  that  the  project  baseline  is  developed  and  that 
the  acquisition  is  totally  documented.  The  configuration 
management  contract  deliverable  requirements  should  be  identified 
in  the  Statement  of  Work  (SOW)  and  in  the  CDRL/Data  Item 
Description  (DID)  to  ensure  contractor  compliance  in 
configuration  management. 

Lessons  Learned 

The  tailoring  of  standards  is  a  labor-intensive  task.  Be  sure  to 
allot  sufficient  time  and  resources  during  preparation  of 
procurement  requests  and  RFPs  for  this  task.  In  addition,  be 
sure  to  assign  sufficient  staff  with  the  necessary  skills  and 
information.  Improper  tailoring  of  the  standards  that  are 
invoked  can  lead  to  considerable  unnecessary  costs  to  a  project. 

In  cases  where  a  specification  is  sent  to  industry  for  comment 
prior  to  finalizing,  request  industry  to  provide  recommendations 
for  tailoring  the  standards  referenced  in  the  specification. 

Responsibilities 

The  PM  is  responsible  for  the  selection,  application  and 
tailoring  of  standards  for  consistency  with  NAS  System 
Specification  objectives,  operational,  NAILS  and  maintenance 
requirements,  and  cost  considerations. 

Review  and  Approval 

FAA  specifications  are  reviewed  through  the  Specification  Review 
Board  process.  At  the  completion  of  this  process,  the 
specification  is  baselined  by  the  division  CCB .  Any  changes  to 
technical  standards  or  general  equipment  requirements  after  the 
specification  has  been  baselined  must  be  made  through  the 
configuration  management  process. 

Contacts 

Additional  information  concerning  technical  standards  and  general 
equipment  requirements  can  be  obtained  from: 

o  ASE-600,  202-287-8644,  Engineering  Specialties 

o  ASE-3.1,  202-287-8654,  Configuration  Management 
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Reference  Documents 


The  following  documents  are  the  basis  for  the  guidelines 
presented: 

o  NAS-MD-001,  NAS  Subsystem  Baseline  Configuration  and 
Documentation  Listing 

o  NAS-SS-1000,  NAS  System  Specification,  Volume  I, 

Functional  and  Performance  Requirements  for  the  NAS, 
General 

o  Order  1830. 2B,  Telecommunications  Standards  Selection  and 
Implementation  Policy 

o  Order  1800. 8F,  NAS  Configuration  Management 

o  FAA-G-2100F,  Electronic  Equipment,  General  Requirements* 

Point  of  Contact  for  Chapter  14  is  Rebecca  Taylor,  ASE-600, 
202-287-8649 . 


FAA-G-2100  has  undergone  major  revision.  The 
specification  is  designed  to  be  tailored  for  COTS  and  NDI 
procurements.  A  tailoring  guide  has  been  included. 

Format  is  consistent  with  FAA-STD-005. 
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Chapter  15 


Introduction 

This  chapter  describes  the  issues  and  activities  involved  in  the 
management  of  system  acquisitions  which  include  software 
components.  It  identifies  the  major  causes  of  software 
acquisition  problems,  outlines  the  software  development  process, 
and  describes  the  various  goals,  issues,  information  requirements 
and  management  strategies  and  activities  for  each  phase  of  the 
software  acquisition  effort. 

The  Software  Problem 

Dr.  Winston  W.  Royce,  a  pioneer  in  software  process  research, 
said  in  1987:  "The  construction  of  new  software  which  is 
pleasing  to  both  user  and  buyer,  and  does  not  contain  errors,  is 
an  unexpectedly  hard  problem.  It  is  perhaps  the  most  difficult 
problem  in  engineering  today.  It  is  often  referred  to  as  the 
'software  crisis'.  It  has  become  the  longest  continuing  'crisis' 
in  the  engineering  world,  and  it  continues  unabated." 

Software  development  is  truly  the  "tar  pit"  of  system 
development.  It  is  all  too  frequently  characterized  by  computer- 
based  systems  that  did  not  meet  user's  requirements,  software 
that  failed  when  needed,  or  exceeded  its  development  budget,  or 
overran  the  schedule,  or  that  was  used  once  and  could  not  be 
reused,  or  that  could  not  be  reasonably  maintained.  The  problem 
is  exacerbated  by  senior  managers  who  typically  are  more 
comfortable  with  hardware  development  and  may  not  be  software 
literate;  they  do  not  recognize  or  understand  the  major  issues  of 
software  development,  are  unimpressed  by  current  software 
development  technologies,  are  unwilling  to  invest  in  training, 
and  fail  to  accept  that  software  is  an  engineering  science 
requiring  analysis  and  design.  As  a  result,  managers  tend  to 
underbid  or  underfund  software  development.  Software  customers 
also  contribute  to  the  quagmire  by  placing  primary  emphasis  on 
computer  hardware,  rather  than  software,  by  underfunding  software 
development,  by  underestimating  the  schedule  demands,  and  by 
failing  to  adequately  establish  user  needs  and  requirements. 

Also,  too  many  software  engineers  oversell  their  product  and/or 
are  trained  as  programmers  rather  than  as  software  engineers . 

Software  is  invisible  and  intangible  -  simply  the  state  of 
electronic  components.  Its  strengths  and  its  weakness  both  lie 
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in  its  inherent  flexibility.  Software 
should  be  considered  as  a  set  of 
representations  of  an  intellectual 
concept.  The  more  people  involved  with 
intimately  understanding  that  concept, 
the  more  difficult  it  becomes  to 
maintain  consistency  and  direction. 

This  is  the  reason  software  has  very 
specific  limits  with  respect  to 
productivity,  and  why  the  difficulties 
rise  exponentially  with  the  size  and 
complexity  of  the  software  developed. 

The  "soft"  in  software  does  not  mean  un¬ 
engineered,  although  software 
development  may  involve  approaches  and  methodologies  which  may  be 
new  to  you.  Software  development  is  at  least  as  complex  as  pure 
hardware  development.  Because  of  software's  malleable  nature, 
the  engineering  discipline  that  we  normally  expect  from  a 
hardware  development  is  even  more  critical  in  software 
engineering.  Even  if  you  are  responsible  for  an  acquisition 
rather  than  the  actual  development  effort,  remember  that  it  is 
almost  impossible  to  manage  or  control  a  software  acquisition 
project  without  intimate  familiarity  with  the  techniques  and 
methods  used  by  your  contractor. 

Managing  a  software  development  or  acquisition  requires  a  great 
deal  of  planning,  considerable  understanding  of  and  insight  into 
the  development  process  as  implemented  by  the  contractor,  the 
ability  to  distil  truth  and  meaning  from  an  avalanche  of 
information,  and  in  some  cases  a  good  deal  of  just  plain  luck. 

The  following  sections  approach  software  development  from  that 
perspective,  and  particularly  from  the  point  of  view  of  the 
Program  Manager  (PM)  and  the  Government  Technical  Representative 
(GTR) ,  i.e.  Technical  Officer's  Representative  (TOR),  Contracting 
Officer's  Technical  Representative  (COTR) ,  or  Contracting 
Officer's  Representative  (COR)  in  an  acquisition  setting. 

The  Software  Process 

The  software  engineering  process  is  not  a  whole  new  entity.  It 
draws  heavily  from  traditional  system  engineering  in  that  it  is 
based  on  establishing  requirements,  doing  trade-offs,  allocating 
requirements,  analytically  and  systematically  decomposing 
requirements,  tracking  interfaces  and  assuring  component  and 
system  compliance  with  requirements.  The  product  of  the 
engineering  process  is  a  set  of  documents  —  not  a  widget. 
Development  and  production  fall  out  of  the  engineering  process. 
This  is  especially  true  of  software,  since  the  actual  product  is 
essentially  an  engineering  representation. 
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One  way  to  view  the  software 
development  process  is  through 
a  model  or  set  of  steps . 

Several  models  have  been 
developed  over  the  years,  and 
each  has  its  strengths  and 
weaknesses  (see  sidebar) .  All 
of  the  models,  however,  depend 
on  the  applicability  to  the 
task  and  integration  with  the 
developer' s  processes  to  be 
useful .  The  PM  or  APME  may 
decide  to  utilize  a  particular 
lifecycle  model  to  enhance 
visibility  of  certain  parts  of 
the  acquisition,  or  to  mitigate 
risks  associated  with  the 
project . 

Software  engineering  is 
comprised  of  several  activities 
all  with  the  goal  of  ensuring 
the  system  designed  and  built 
meets  the  user's  requirements. 

It  takes  as  its  inputs  the  set 
of  requirements  allocated  to 
software  by  system  engineering.  This  single  fact  points  out  the 
immense  importance  of  proper  system  engineering.  If  the  software 
is  not  part  of  the  system  engineering  decomposition  and  is  simply 
the  leftovers  that  didn't  fit  on  the  board,  the  success  of  the 
project  is  almost  impossible. 

The  software  engineering  activities  can  be  summarized  as  follows: 

Requirements  Analysis  and  Decomposition  -  This  activity  consists 
of  formulating  and  restating  the  requirements  allocated  from  the 
system  engineering  process  and  identifying  "derived”  requirements 
which  are  necessary  to  meet  those  that  are  allocated.  These 
derived  requirements  are  then  hierarchically  decomposed  into  sets 
of  smaller  subsets  until,  at  the  bottom  level,  there  exists  a  set 
of  subsystems  which  are  of  manageable  size  to  build.  Each 
subsystem  has  explicit  requirements.  This  process  results  in 
software  requirement  specifications  and  software  test  plans. 

Interface  Control  -  Software  system  engineering  is  the  keeper  of 
the  interface  specifications  among  the  software  subsystems  and 
modules.  As  problems  require  the  redefinition,  rethinking  and 
change  of  subsystems,  the  software  system  engineer  ensures  that 
the  interfaces  with  other  subsystems  remain  viable. 

Software  Design  -  The  design  stage  of  software  engineering 
consists  of  determining  the  software  system  architecture  and 
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allocation  of  requirements  to  the  module  level.  This 
architectural  design  is  usually  the  most  critical  area  in 
software  systems.  Once  the  architecture  is  established,  detailed 
design  consists  of  describing  the  interfaces  between  modules,  the 
data  structures,  the  input/output  details,  any  timing  and  memory 
constraints,  and  the  detailed  documentation  of  the  program  flow. 
Test  cases  for  each  of  the  allocated  requirements  are  also 
developed.  This  stage  is  normally  accomplished  by  programmer/ 
analysts  or  programmers. 

Coding  and  Unit  Testing  -  This  is  the  actual  programming  of  the 
system  from  the  detailed  flows  created  above,  and  if  all  previous 
work  has  been  done  well,  should  be  relatively  straight  forward. 
Once  a  module  has  been  coded,  it  is  tested  against  the  test  cases 
developed  in  the  system  design  to  observe  the  output. 

Integration  of  Software  Units  into  Systems  -  As  each  of  the 
hierarchical  design  levels  are  coded  and  unit  tested,  they  are 
built  back  up  into  larger  and  larger  modules  and  tested  together. 
Once  the  entire  software  system  has  been  built  and  tested,  it  is 
provided  to  the  system  engineers  for  hardware/software 
integration  and  system  level  testing. 

Operations  and  Maintenance  -  Although  not  strictly  a  software 
engineering  phase,  many  problems  and/or  changes  in  requirements 
show  up  only  after  the  system  enters  operation.  Such  changes 
lead  to  an  iteration  in  the  development  cycle  to  accommodate  the 
modifications.  Obviously,  software  which  has  been  crafted  with 
maintenance  and  modification  in  mind  is  much  more  maintainable 
than  otherwise. 

Software  Acquisition  Management 

Now  that  we  have  a  general  feel  for  what  the  developer' s  supposed 
to  be  doing,  we  can  address  the  PM  and  APME  responsibilities  and 
activities.  The  management  tasks  fall  into  4  roughly  sequential 
phases:  Planning,  Evaluating  Offerors,  Monitoring  the 

Development,  and  Supporting  (Surviving)  OT&E.  OT&E  is  addressed 
in  Chapters  6,  7,  and  8  of  this  Guide. 

Software  Acquisition  Planning 

The  most  important  phase  in  software  acquisition  is  the 
preparation  for  issuing  the  Request  for  Proposals.  The  PM  and 
APME  are  responsible  for  their  own  destiny,  since  everything  that 
they  will  want  or  need  to  do  during  the  contract  must  be  planned 
for  before  the  contract  is  awarded. 

Planning  Goals:  The  primary  goals  of  the  planning  activity 
are  to  establish  a  supportable,  consistent  strategy  for 
managing  the  software  acquisition  and  to  develop  a  Statement 
of  Work  that  supports  that  strategy. 
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Planning  Issues :  The  major  issues  in  this  phase  are 
resources,  requirements  volatility,  schedule  and  risk. 

Required  Information  for  Planning: 

o  Size  and  complexity  of  software  (estimate) 

o  Safety  critical  software  requirements 

o  Preliminary  Risk  Assessment 

o  Commercial  Off  The  Shelf  (COTS)  products  which  might  be 
used 

o  Quality  of  requirements  or  specification 
o  Budget  and  other  resources 


Planning  Strategies  and  Techniques: 


The  Software  Acquisition  Management  Plan  (SAMP) :  Of 
primary  importance  to  the  acquisition  manager  is  a 
software  management  plan.  This  outlines  the  scope  of  the 
software  development,  the  schedules  for  the  various 
reviews,  describes  what  documentation  will  most  likely  be 
provided,  who  will  review  it  and  how,  and  what  resources 
are  available  to  support  the  APME  or  GTR.  This  is  also 
the  place  to  begin  to  determine  what,  if  any,  management 
or  software  metrics  will  be  required,  what  tools  might  be 
utilized,  how  the  Government  will  monitor  the  technical 
development,  and  other  technical  and  management  questions 
which  will  need  to  be  addressed  in  the  Statement  of  Work. 
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The  Concept  of  Operations  (CONORS)  Document: 
This  document  describes  in  user  terms  how 
the  system  should  work.  It  is  written  by 
the  user  early  in  the  program  initiation 
phase,  and  becomes  the  basis  of  formal 
requirements  analysis  later  in  the  program. 
The  CONOPS  is  presented  as  a  section  within 
the  Operational  Requirements  Document.  The 
new  version  of  DOD-STD-2167  (to  be  called 
DOD-STD-498) ,  upon  which  FAA-STD-026  is 
based,  contains  a  Data  Item  Description  for 
a  complete  CONOPS  document . 

The  Statement  of  Work  (SOW) :  Each  project 
has  a  single  statement  of  work,  and  software 
may  be  a  small  part  of  it .  However,  no 
document  is  more  important  in  designating  to 
the  contractor  what  he  is  required  to  do. 

The  SOW  is  a  contractual  document,  and  the 
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Government  will  live  with  it  throughout  the  contract 
life.  Thus,  it  behooves  the  PM  and  GTR  to  craft  the  SOW 
very  carefully.  This  document  is  prepared  for  inclusion 
in  the  Request  for  Proposal  (RFP)  which  is  sent  to 
contractors  soliciting  a  bid.  Items  to  be  addressed 
should  include  reporting  requirements  for  metrics, 
specification  of  programming  language,  documentation 
formats  {electronic  or  paper) ,  risk  management,  technical 
teams  and  support  for  Government  access  to  the  work 
products  in  progress. 

Work  Breakdown  Structure;  The  Work  Breakdown  Structure 
(WBS)  is  one  of  the  best  ways  to  get  an  understanding  for 
the  project  at  hand.  By  creating  mini-plans,  called  work 
packages,  for  each  low  level  task  it  is  possible  by 
summing  up  the  hierarchy  to  estimate  the  cost,  resources, 
and  schedule  for  each  activity  up  to  and  including  the 
entire  project.  The  WBS  can  be  created  in  many  different 
ways,  depending  upon  how  the  work  is  visualized. 

However,  those  WBSs  which  are  most  effective  are  closely 
related  to  the  product  breakdown  structure  or  interleave 
products  with  processes.  This  approach  yields  a 
breakdown  based  on  finite  objects,  the  products,  and 
allows  effective  delegation  of  control  as  well  as 
responsibility  for  product  completion.  A  WBS  which 
describes  too  many  functions  (on-going,  level-of-ef f ort 
activities)  rather  than  products  tends  to  have  no  one 
responsible  for  anything,  except  at  the  highest  levels. 
This  prevents  PMs  from  using  the  WBS  to  benefit  the 
project  planning  and  organizing.  The  WBS  provided  in  the 
typical  solicitation  for  a  typical  project  is  three  or 
four  levels  deep,  but  in  a  large  project  may  go  to  the 
eighth  level,  or  more.  You  may  wish  to  specify  a  desired 
or  required  WBS  in  the  RFP  or  you  may  use  the  Government 
developed  WBS  for  comparison  against  proposed  WBSs.  You 
should  specify  to  which  level  the  WBS  should  be  tracked 
and  to  which  it  should  be  reported.  A  good  rule  of  thumb 
is  to  have  the  contractor  track  to  two  levels  deeper  than 
you  wish  reported. 

Size,  Cost  and  Schedule  Estimation:  The  Government  cost 
estimate  is  a  primary  means  of  evaluating  proposals; 
however,  estimating  the  size  of  the  software  component  of 
a  system  is  essential  to  all  planning  activities.  It  is 
also  very  difficult  and  should  be  left  to  experts 
whenever  possible.  Some  estimation  techniques  are 
described  in  the  sidebar,  but  seek  advice  wherever 
possible  and  never  use  only  one  estimating  technique  for 
your  planning. 

Risk  Management  Plan:  Before  an  RFP  is  released  or  a 
contract  is  awarded  the  PM  and  APME  should  develop  a  risk 
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Tecbaiqu^ 

Estimation  fyfAMhgy  -  $m  is  e^imated  by 
using  ih&  £^!ts  of  anoiher  ^milar  {trojoci.  It 
is  inaccoratc  If  the  anafo^  Is  not  exact,  and 
fails  completely  for  first-bf-a-kinil  systems.  If 
Isnottecommcndcd, 

Jtute-o/-Thm0  -This  method  involves  using 
guidelines  <ttiIes-or*Uiuinb)'fof  estimadon.  For 
example,  if  we  believe  the  system  requires 
45iC  tines  of  smuee  code,  and  we  know  that 
our  productivity  is  150  Jin^  of  code  per  staff 
mtmdi  (life  3»I&^f-thumbXll®n  the  job  will 
take  300  staff  months  of  ^oft.  This  method  is 
genetalfy  used  a  sanity  check. 

Design  to  Cost  md  Schedfde^ «  This  is  realty 
an  engineering  apjsoach.  If  we  have  10  pqopte 
and  1$  months  available,  and^^^oar  typical 
productivity  rate' for  such,  a  System  is  20O 
hoc  per  smff  month,  we  estimate  we  can 
design,  build,  and  test  36,000  lines  of  code.  . 
B0t(0m-up  WBS  BsUmaiim  -  If  the  project  ba^ 
.been  subjected  to  WBS  analysis,  dtC  bottom  . 
level  tasks  may  be  estimated  and  then  toiled  ' ' 
up  into  an  ov^ail  esiimaje.  This  is  probably 
the  most  reliable  method  of  estimadon,  if  ait 
facets  of  the  project  are  understood. 

C<?CWC?  -  This  is  one  of  several  modeling 
techniques  for  estimation  vdiich  are  .  . 
obstructive;  they  h^e  historical  data  and  > 
'^construct**  a  ftutnula.  The  equations  me 
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COsi/scl^uIe  drivers.  This  technique  is  tinJy 
valid  if  the  equations  and  factors  have  been 
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'the  oiganizarion  Involved,^ 

Function  Points  -  This  method  counts  inputs, , 
Outputs,  queries,  files,  and  interfaces.  These 
s  are  then  weighted:  according: to  complexity  and 
adjusted  by.  various  factors  to  obtain  an 
estimate.  '  , 


management  plan  (RMP)  which 
specifically  deals  with  software 
issues.  This  may  be  part  of  a 
larger  RMP  or  the  software 
development  plan,  but  it  is  an 
important  means  of  determining 
areas  for  special  consideration 
in  the  SOW  generation  and 
proposal  evaluation  activities. 
For  example,  development  metrics 
or  technical  performance 
parameters  are  often  used  to 
provide  trigger  information  for 
contingency  plans,  and  therefore 
must  be  specified  as  part  of  a 
deliverable  in  the  SOW. 

Particular  technological  risks, 
such  as  algorithm  stability,  may 
require  more  experience  from  the 
company  and  thus  affect  the 
technical  evaluation  rankings. 

You  should  become  familiar  with 
the  types  of  risks  encountered  in 
software  development,  and  prepare 
a  risk  mitigation  plan.  The 
Software  Capability  Evaluation 
process  described  beginning  on 
page  15-8  can  provide  valuable 
insight  into  risk  areas  for  each 
particular  contractor  as  well  as 
the  project  as  a  whole.  Training 
in  this  area  is  offered  in  the 
Software  Acquisition  Management 
course . 


Standards  and  Documentation;  The 
FAA  standard  for  software 
development  is  FAA-STD-026.  This 
”  *'■  standard  points  to  DOD-STD-21 67A 

^^d  levies  additional  FAA 
specific  requirements.  FAA-STD- 
026  is  the  most  comprehensive  and  consistent  software 
standard  available  for  managing  FAA  software  contracts. 
Both  standards  specify  all  documentation,  formal  reviews, 
and  audits  which  could  possibly  be  required  on  any 
software  project  which  uses  the  methodology.  The 
mechanism  for  such  document  specification  is  the  data 
item  description  (DID) .  The  PM  and  APME  are  expected  to 
extensively  tailor  (i.e.,  customize)  all  SOW, 
documentation  requirements  and  specifications  before 
including  them  in  the  RFP .  Other  FAA  standards  with 
which  the  PM  and  GTR  should  be  familiar  include  RTCA  DO- 
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178B  which  describes  the 
certification  of  avionics 
software  and  the  Ada 
development  language 
specification  MIL-STD-1815A. 
DO-178B  can  be  used  in 
conjunction  with  or  in  lieu  of 
FAA-STD-026,  particularly  for 
contractor  maintained  systems. 

Evaluating  Software  Developers 

Obtaining  a  contractor  with  a 
good  chance  of  success  in  a 
software  project  is  not  a 
trivial  task.  This  section 
describes  the  three  activities 
which  can  best  improve  your 
chances  of  getting  a  competent 
software  developer  -  the 
Software  Capability 
Evaluation,  the  Software  Development  Plan,  and  the  Evaluation 
Criteria  used  in  Sections  L  and  M  and  in  the  Technical  Evaluation 
Plan . 

Evaluation  Goals:  The  primary  goal  in  this  phase  is  to  make 
sure  that  the  contractor  selected  for  the  acquisition  (and/or 
the  subcontractor (s)  responsible  for  the  software)  is  capable 
of  performing  the  development  with  a  significant  chance  of 
success  within  schedule  and  budget  constraints. 

Evaluation  Issues:  The  major  issues  in  this  phase  are  the 
technical  evaluation  criteria,  the  weighting  of  those 
criteria,  and  the  validity  of  the  information  used  to  evaluate 
the  offerors. 

Required  Information  for  Evaluation: 

o  Size  and  complexity  of  software  (estimate) 
o  Risk  Management  Plan 

o  Technical  Evaluation  Plan  and  Materials 
o  Safety  critical  software  requirements 

o  Likely  number  of  bidders  and/or  software  subcontractors 

Evaluation  Strategies  and  Techniques: 

The  Software  Capability  Evaluation  Process:  Probably  the 
most  effective  tool  for  evaluating  the  capabilities  of  a 
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pacJk^fts. TraiflingisdsooffdiWfey iheSESG  offerors  and/or  their  software 
on  a  period  to  basts  in  ,  subcontractors  being 

considered.  The  evaluation  is 
wmmmmmmmmmmmmmmmmmmmmmmmmimmmmmm  based  on  work  performed  at  the 

Software  Engineering  Institute, 
a  FFRDC  at  Carnegie  Mellon  University.  The  SCE  uses  a 
well-documented  and  historically  validated  process  to 
evaluate  the  contractor  in  18  Key  Process  Areas.  The 
results  may  be  used  to  determine  probability  of  success, 
areas  of  risk,  and  overall  maturity  of  the  organization 
evaluated.  The  process  is  not  inexpensive  -  the  average 
cost  is  between  $15-25K  per  evaluation  performed  -  but  it 
has  been  shown  beneficial  to  both  the  acquiring  agency 


and  the  offeror.  The  project  needs  to  consider  the 


weight  the  SCE  will  have  in  selecting  the  successful 


offeror . 


The  Software  Development  Plan: 

’  RESOUR<^:  ■■  Experience  has  shown  that  the 

Bruce  Siebenthalf, Rich Tiifner and  John' ■■  Software  Development  Plan  can  be 

Hamihon  in  AHN*5CXJ  have  boeh  involved  .  •  ••  effectively  used  as  the  basis  for 
with  the  SCB  process  and  can  isrovide  more  ■  acquiring  software  development 
dctaiM  mfomattoo-  AdcfiUonaily,  the  SESG  -  information  in  the  proposal, 
is  studying  the  BAA  policy 'with  respect  to  This  plan  describes  the  manner  in 

SCB  and  has  several  SEhtraincd  individuals.  ^  which  a  satisfactory  software 
An  example  of  a  SAjMP  can  be 'Obtained  from  product  will  be  achieved  within 

Bruce  Sicbcnthall.  SESG  Is  working  on  a  set  schedule  and  budget 

.  of  guideline  for  the  SAMP. ■  constraints.  It  specifies  the 

-  ‘  . 'y  '  ,  processes  the  contractor  will  use 

to  build  a  system  that  satisfies 
the  requirements  specification 
and  SOW.  It  also  specifies  the  software  products  to  be 
developed,  the  organizational  relationships  of  the 
project,  the  roles  and  responsibilities  of  development 
personnel,  the  reporting  and  control  mechanisms,  the 
tasks,  schedules  and  staffing,  and  the  plan  for  updating 
the  software  development  plan.  There  are  sections  on 
testing,  configuration  management,  and  product 
evaluation.  This  plan  is  of  particular  value  in  that  it 
indicates  the  contractor's  breadth  and  depth  of  planning. 
It  allows  the  Government  to  assess  the  consistency  of 
cost,  schedule,  and  resource  estimates,  and  shows  the 
contractor's  understanding  of  the  project.  Additionally, 
it  provides  a  basis  for  assessing  progress  and  for 
controlling  the  project.  The  software  development  plan 
is  described  in  FAA-STD-026,  which  points  to  DOD-STD- 
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2167A,  and  Data  Item  Description  (DID)  DI-MCCR-80030A. 
FAA-STD-026  and  the  DID  can  be  used  as  the  source  for 
proposal  requirements,  criteria,  and  guidance  to  insert 
in  Sections  L  and  M  of  the  RFP .  By  including  the  plan 
requirement  and  associated  efforts  in  the  SOW  and 
contract  data  requirements  list,  it  will  become  a  binding 
part  of  the  contract.  When  evaluating  SDP  information, 
look  for  specifics,  particularly  examples  from  previous 
projects.  Don't  accept  motherhood  or  boilerplate.  If 
the  contractor  can't  be  specific  about  exactly  how  their 
software  development  will  be  performed  in  the  proposal, 
they  certainly  will  have  a  very  little  chance  for  success 
in  the  heat  of  the  development  effort.  SDP  type 
information  provided  in  the  proposal  should,  if  possible, 
be  corroborated  by  the  results  from  an  SCE. 

Evaluation  Criteria  and  Scoring:  The  basic  strategy  in 
determining  evaluation  criteria  is  to  isolate  those  areas 
which  will  provide  the  most  discrimination  between 
superior  contractors  and  the  rest  of  the  pack.  This  can 
be  accomplished  within  the  context  of  risk  assessment, 
technology  evaluation,  or  from  the  experiences  of  similar 
projects.  Of  major  concern  is  that  whatever  criteria  are 
determined  to  be  important  not  be  buried  at  so  low  a 
level  that  they  have  no  bearing  on  the  technical  scoring. 
One  way  which  has  been  effective  is  to  make  a  reasonable 
percentage  (30-50%)  of  the  technical  score  directly  based 
on  the  SCE  results  and/or  the  SDP  information  evaluation. 
One  factor  often  overlooked  in  evaluations  is  the 
information  provided  to  the  FAA  evaluators.  The 
Technical  Evaluation  Plan  should  be  detailed  enough  to 
provide  guidance  to  the  reviewers  as  to  what  is 
acceptable  and  what  is  not  with  respect  to  software. 
Comprehensive  evaluation  materials  are  worth  their  weight 
in  gold  when  you  have  a  large  evaluation  team,  not  to 
mention  their  value  in  the  case  of  a  protest . 

Monitoring  Software  Development  Activities  in  Acquisition 

The  day-to-day  monitoring  of  a  software  development  project  can 
be  challenging  at  best  and  a  nightmare  if  approached  in  a  laissez 
faire  manner.  Much  of  the  success  of  this  effort,  however, 
depends  on  how  well  the  planning  and  evaluation  activities  were 
performed.  It  may  be  necessary  to  modify  contracts  where  the 
planning  was  insufficient.  While  this  may  result  in  overall 
higher  costs,  the  probability  of  success  should  increase  enough 
to  where  it  is  larger  than  the  probability  of  failure. 

Monitoring  Goals:  The  primary  goals  of  the  monitoring 
activity  are  to  maintain  planned  cost  and  schedule  and  to 
ensure  project  success. 
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Monitoring  Issues:  The  major  issues  in  this  phase  are 
information  accuracy  and  management,  contractor  access, 
requirements  volatility,  schedule  and  risk  management. 

Required  Information  for  Monitoring: 

o  Statement  of  Work 

o  Risk  Management  Plan 

o  SAMP 

o  Metrics 

o  SDP 

Monitoring  the  Development:  Monitoring  software  development 
does  not  occur  in  a  vacuum,  and  it  is  at  least  useful,  if  not 
essential,  to  integrate  the  software  monitoring  with  the  rest 
of  the  program  management  effort. 

Cost  Performance  Reporting:  Most  programs  will  include  a 
cost  performance  reporting  system  in  major  contracts. 
These  systems  require  the  contractor  to  establish  a  work 
breakdown  structure  (WBS)  for  the  contract,  estimate  the 
cost  for  each  WBS  element  and  report  on  actual  costs  and 
work  completed  periodically  at  an  agreed  upon  level  of 
detail.  This  technique  is  especially  useful  in  software 
and  hardware/software  integration  because  the  most 
significant  costs  are  associated  with  labor  and  the 
product  can  not  be  physically  seen  until  very  late  in  the 
process.  Planning  and  requirements  for  cost  and 
progress  reporting  for  software  should  be  integrated  with 
the  program  cost  performance  reporting  requirements. 

This  allows  a  common  WBS,  common  terms  and  definitions, 
and  common  or  integrated  significant  milestones. 

Program  Management  Reviews  and  Surveillance  Plan: 

Periodic  program  management  reviews  and  associated 
contractor  deliverable  data  are  designed  to  assist  the 
Government  in  monitoring  progress  of  the  contract. 
Requirements  for  these  reviews  and  associated  data 
deliverables  are  included  in  the  statement  of  work  and 
contract  data  requirements  list.  In  complex  acquisition 
situations  it  is  helpful  to  prepare  a  surveillance  plan 
describing  the  activities  and  responsibilities  of  the 
various  Government  organizations  monitoring  the 
contractor.  This  can  help  avoid  duplication  of  effort, 
improve  communications  and  decrease  the  chances  of 
Government  organizations  working  at  cross  purposes.  The 
surveillance  plan  can  be  incorporated  as  part  of  the 
SAMP  . 
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Contractor  Plans:  Contractor  internal  plans  for 
management,  metrics,  reporting,  etc.  should  support  the 
contract  requirements.  If  Government  requirements  are 
flexible  enough  to  allow  the  contractor  to  use  suitable 
established  systems,  savings  in  cost  and  confusion  can  be 
realized.  Levying  performance  management  requirements  on 
a  contractor  can  also  encourage  contractors  to  establish 
suitable  systems  where  none  currently  exist.  This  is 
beneficial  to  both  the  contractor  and  Government. 

Monitoring  Strategies  and  Techniques: 

Incremental  Design  Reviews  and  Demonstrations:  Probably 
the  major  contributor  to  software  project  failure  is  the 
"big-bang"  approach  to  development  where  all  the  work  is 
done  somewhat  in  parallel,  and  come  integration  time 
everything  is  thrown  together  to  see  if  it  works.  If  it 
does  (rare  event)  then  all  is  well/  if  it  doesn't  then 
there  are  major  problems.  Theoretically,  design  reviews 
are  supposed  to  prevent  the  big  bang  from  occurring,  but 
all  to  often  the  reviews  are  controlled  by  the  contractor 
and  present  very  limited  visibility  into  the  actual 
development  process.  This  is  particularly  true  in 
software.  One  way  to  avoid  this  syndrome  is  to  require 
incremental  demonstrations  of  capabilities  rather  than 
paper  reviews.  These  must  be  addressed  in  the  SOW  and 
therefore  planned  for  early  in  the  development.  This  is 
an  excellent  way  of  forcing  the  contractor  to  address 
architectural  problems  early  on  in  the  development  and, 
if  the  demonstration  capabilities  are  carefully  thought 
through,  prevent  the  contractor  from  concentrating  on  the 
easy  requirements  first  and  leaving  the  difficult  effort 
for  later  where  schedule  and  budget  are  under 
considerably  more  pressure. 

Metrics  or  Management  Indicators:  Considerable  work  has 
been  done  in  establishing  objective  indicators  which  can 
be  observed  and/or  computed  throughout  a  software  project 
to  assess  progress.  By  requiring  the  contractor  to 
accumulate  and  report  these  indicators,  it  becomes 
possible  to  track  progress  using  a  "shorthand"  method. 
There  are  different  flavors  of  metrics,  all  of  which  have 
utility  in  software  development  projects.  Project 
control  metrics  include  such  things  as  earned  value 
analysis  for  task  tracking.  Quality  assurance  metrics 
assess  the  degree  to  which  a  pre-stated  objective  for  a 
task  was  met.  Performance  metrics  measure  performance, 
usually  with  regard  to  some  requirement.  Again,  the 
delivery  of  these  metrics  must  be  specified  in  the  SOW. 

Risk  Contingency  Plans  and  Corrective  Action:  When 
problems  inevitably  arise  corrective  action  must  be 
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'  T^$lS0'fubll#es:a-5<^H«r^  - 

■  ■ '-'  applied.  This  action  is 

,,  fcoiir^ in ihe subject.  -  '■■  '  '  concerned  with  bringing  the 

-  ,  •':■  '  status  of  the  project  into 

conformance  with  applicable 
requirements,  budget,  schedule, 
plans,  standards,  guidelines,  policies,  and  procedures. 
For  corrective  action  to  be  effective,  good  project 
control  mechanisms  must  be  available,  and  effective 
status  and  visibility  techniques  must  be  in  place.  Good 
risk  management  and  contingency  planning  eases  the  strain 
of  problem  handling,  but  most  PMs  are  not  prescient,  so 
problems  will  occur.  If  contingency  plans  are  in 
existence,  response  to  a  problem  is  straight  forward. 
Otherwise,  there  is  still  a  continuum  of  actions  which 
might  be  taken  -  do  nothing,  bring  the  project  into 
conformance  with  plans  and/or  requirements,  change  plans 
and/or  requirements  to  make  them  conform  to  the  actual 
state  of  the  project,  modify  both  the  plans  and  project 
status  to  achieve  conformance,  or  cancel  the  project. 

One  good  solution  is  trading  off  the  requirements  against 
budget  and/or  schedule,  if  possible.  All  too  frequently, 
the  manager  blindly  increases  resources  to  bring  the 
schedule  back  within  bounds;  unfortunately,  few  software 
problems  respond  to  a  brute  force  approach. 

Testing:  The  Government  must  require  thorough  testing  of 

all  software  products.  The  responsibility  of  the  GTR  is 
to  oversee  preparation,  by  the  contractor,  of  the  test 
documents.  He  is  also  responsible  for  overseeing  the 
testing  itself,  and  for  accepting  the  final  product. 

This  should  be  a  continuing  process,  not  left  until  the 
last  months  of  the  project.  Test  plans  should  be 
generated  at  the  same  time  as  specification  and 
requirements  documents.  The  key  instrument  for  control 
of  testing  by  the  GTR  is  review  of  the  test  plans,  the 
test  cases,  and  the  test  procedures .  By  carefully 
ascertaining,  at  each  step  of  the  process,  that  all 
requirements  are  tested  by  the  plan,  then  by  observing 
the  test  and  reviewing  the  test  results,  the  GTR  assures 
the  Government  will  receive  a  quality  product. 

Reviews,  Inspections,  and  Walkthroughs:  There  are  many 
types  of  progress  reviews:  weekly  status  meetings, 
demos,  quarterly  reviews,  milestone  reviews,  etc.  The 
major  value  of  a  review  lies  in  the  preparation  and 
follow-up.  For  a  progress  review  to  be  effective,  action 
items  must  be  tracked  by  assigning  a  responsible  party 
and  due  date,  and  demanding  resolution.  Open  action 
items  become  the  subject  of  follow-up  reviews.  The  PM 
and  GTR  should  specify  an  appropriate  level  of  review 
activity  in  the  SOW  and  contract.  Inspections  consist  of 
peer  review  of  work  products,  such  as  specifications. 
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plans  and  code.  Tailored  checklists  are  used  to  guide  the 
effort.  The  results  of  the  inspection  are  analyzed  for 
trends  and  recurring  types  of  mistakes.  They  are  highly 
recommended  to  catch  misunderstandings  early-on, 
especially  since  the  cost  of  finding  and  fixing  a  mistake 
at  this  stage  of  the  development  process  is  significantly 
less  than  fixing  a  fielded  system.  Walkthroughs  are 
similar  to  inspections,  except  they  are  informal.  The 
author  usually  presents  the  material,  and  checklists  are 
seldom  used.  Their  purpose  is  to  transfer  design 
information  and  interact  with  team  members  working  in  a 
similar  area  of  the  project.  Walkthroughs  are  most 
effective  for  communicating  technical  issues  such  as 
requirements  allocation,  interface  conventions,  and 
architectural  design  structures  among  software 
developers . 


CASEFandaroenfals  :  , 

CASE  is  a  set  of  tools  to  aid  the  system  engineer.  It  uses  automation  of  sophisticated  techniques  and 
documentation  types  to  describe  l>oth  the  processes  and  the  data  relationships  which  ate  required  to 
accomplish  the  project  requirements.  These  diagrams  may  he  thought  of  as  altem^ve  ways  to  describe  , 
the  requiremems  at  a  very  detailed  level  They  may  be  tied  back  to  tte  requirements  model  and  are 
actually  an  evoludmt  of  it  to  a  more  eonctete  and  detailed  stage.  This  stage  is  called  the  “analysis 
phase>’^  and  is  the  logical  mottel  of  the  software  project 

The  next  stage  of  CASE  is  the  “design  pha^,”  which  deals  wih  the  concrete  element^  pf  compute  .  ■  ' 
ptc^tamming  such  as  data  tables  and  progmm  flow  chans.  These  are  gencratkt  by  the  t^l  from  the 
Module  Action  Iliagiams  and  Entity  ^lafionship  EiagraraS  prepared  in  the  previous  phase.  The 
en^n^r  here  works  with  the  order  of  program  flow»  by  rearranging  flow  chart  element,  and  with  dw' 

'  data  stcffage  assodations,  e.g.  &  a  relational  data  base,  by  designing  the  tables.  When  work  is  eomplete  • 
in  this  stage,  the  en^nem*  presses  the  button  and  the  code  for  both  the  program  and  thd)3ata  element  . . 
dictionary  (if  one  is  using  a  DBMS)  are  machine  generated.  This  is  called  the  “construc’don  phase.*^ 
Case  offers  tremendous  potential  by  eliminating  a  ^eat  deal  of  effort  and  staff  in  the  detailed  design . 
and  coding  phases.  However,  the  toolset  is  expensive,  and  engineering  effort  is  both  large  and  highly 
specjali2ed  in  the  analysis  phase.  ,  ^ ' 

:  s  ^  .  -l  > 
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Computer  Aided  System  Engineering  (CASE) :  When  the 
contractor  is  using  CASE  technology  one  way  of  monitoring 
the  development  process  in  a  relatively  unobtrusive  way 
is  for  the  Government  to  acquire  a  full  set  of  the 
contractor' s  CASE  environment  and  require  periodic 
delivery  of  the  development  information  in  the  CASE 
format.  This  allows  the  GTR  and  support  staff  to  analyze 
the  activities,  accurately  evaluate  the  status  and 
maintain  currency  with  design  decisions. 
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The  Software  Engineering  Specialty  Group 

The  Software  Engineering  Specialty  Group  (SESG)  was  established 
to  improve  the  FAA  acquisition,  development  and  maintenance 
processes  for  operational  software.  It  was  intended  to  function 
as  an  expert  resource  to  the  Program  Manager  and  staff,  in  the 
RFP  process,  the  evaluation  of  proposals,  and  throughout  the 
product  lifecycle.  Most  importantly,  the  SESG  is  a  service 
organization,  here  to  help  you. 

The  SESG  has  an  internal  operating  plan  that  defines  specific 
tasks  to  be  accomplished  each  year.  These  tasks  have  been 
developed  by  meeting  with  SESG  "customers"  and  all  tasks  support 
overall  area  improvement  to  the  FAA  in  software  engineering  and 
management.  The  SESG  tasks  address  deficiencies  established  in 
the  approved  SESG  Mission  Need  Statement.  For  the  near  term, 

SESG  will  mostly  be  developing  software  guidelines  and  handbooks, 
providing  training  and  technology  transfer,  providing  software 
consultation  support  to  projects  as  requested  and  as  defined 
within  an  organizational  Memorandum  of  Understanding. 

SESG  Staff  and  Points  of  Contact 


o  Carolyn  Strano,  Mgr,  Eng.  Specialties  and  CM  Division, 
ASE-600,  202-287-8644 

o  Susan  Gardner,  Program  Manager,  202-287-8646 

o  Bill  Norton,  SESG  Standards  &  Handbooks,  SESG  staff  planning 
and  support,  202-287-8708 

o  Cecil  Maccannon,  Project  Consultation,  Training  Coordinator, 
SESG  Workshop,  SESG  Liaison,  202-287-8647 

o  Norm  Simenson,  Project  Consultation,  Software  Capability 
Eval .  Acq.  Self  Assessment,  202-287-8651 

o  Debora  Sery,  SESG  Standards  &  Handbooks,  SESG  INTERFACE 
Newsletter,  SESG  Workshop,  202-287-8658 

o  Shirley  Ginwright,  Project  Consultation,  Software  Eng. 

Forum,  Software  Eng.  Consultation  Lab,  202-287-2643 

0  Stuart  Bell,  SESG  Standards  &  Handbooks,  SESG  Plans, 
202-287-8715 

o  Patrick  Brown,  Software  Acquisition  Guidelines, 

202-287-8648 

o  Linda  Durrett,  Division  Secretary,  202-287-8644 

o  Customer  Assistance  Line,  202-646-4777 
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o  ASE-600  Fax,  202-287-8761 

o  Rich  Turner,  AND  Liaison,  Software  Acquisition  Management 
Course,  202-267-6611 

o  Leo  McNamara,  AIT  Liaison,  202-267-8627 

o  Kim  Taylor,  AOS  Liaison,  202-267-7183 

Point  of  Contact  for  Chapter  15  is  Susan  Gardner,  ASE-600, 
202-287-8646. 
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Chapter  16 


This  chapter  discusses  Order  1810.6,  Policy  For  the  Use  of 
Nondevelopmental  Items  (NDI)  in  FAA  Acquisitions,  November  13, 
1992.  This  order  states  that  the  FAA  shall  examine  the 
opportunities  to  satisfy  mission  requirements  through  the  use  of 
nondevelopmental  items  (NDI)  or  equipment  that  is  available 
without  further  development  work.  Information  is  included  in 
this  chapter  on  some  areas  that  are  particularly  significant  when 
considering  acquiring  nondevelopmental  items.  While  NDI  must 
comply  with  the  same  acquisition  policies  (FAR,  Order  1810.1, 
etc.),  it  is  possible  to  tailor  acquisition  strategies  to  get 
products  and  services  to  the  users  more  quickly  and  for  lower 
costs  than  using  the  traditional  development  of  an  FAA  unique 
item.  However,  we  must  be  willing  to  trade  off  some  "nice-to- 
have"  performance  parameters  for  extra  schedule  and  cost  benefits 
and  consider  support  issues  at  the  beginning  of  the  process,  much 
earlier  than  we  do  in  most  cases  now. 

Process  Description 

When  basic  user  requirements  are  established  in  mission  analysis 
and  the  mission  need  statement  (MNS)  is  developed,  mention  should 
be  made  of  whether  NDI  is  a  possible  option  for  any  acquisition 
solution.  In  most  FAA  acquisitions,  this  should  be  a  viable 
option.  If  NDI  is  a  possible  option,  it's  feasibility  must  be 
analyzed  and  input  to  the  decision  on  acquisition  strategy. 
Analysis  is  supported  by  market  surveillance  and  investigation. 
Market  surveillance  is  formally  defined  as  a  continuing  and 
ongoing  effort  to  stay  technically  current  in  areas  of  agency 
interest  or  expertise.  The  FAA  does  not  currently  conduct  a 
formal  systematic  program  of  market  surveillance;  however,  recent 
experience,  publications,  and  marketing  information  received  from 
industry  are  sources  of  market  surveillance  information. 

If  the  information  available  from  market  surveillance  indicates 
that  NDI  may  be  a  suitable  solution,  a  more  specific  and  detailed 
evaluation  of  suitability  is  conducted  to  support  the  NDI 
decision.  This  information  is  obtained  through  market 
investigation,  defined  as  activity  conducted  before  an  initial 
milestone  review  decision  on  pursuing  NDI .  Market  investigation 
provides  the  basis  for  finalizing  the  requirements,  developing^ 
the  specification,  determining  test  requirements,  and  determining 
logistics  support  requirements.  Methods  to  obtain  information 
can  include  testing  of  samples,  information  from  independent  test 
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activities,  and  surveys.  Note  that  the  requirements  documents 
and  specifications  are  not  completely  firm  until  after  this  step, 
when  the  appropriate  tradeoffs  are  made.  This  is  a  fundamental 
difference  in  process  because  it  is  not  assumed  that  the 
system/equipment  will  be  built  in  accordance  with  a 
specification.  This  decision  is  part  of  the  acquisition  plan  and 
other  documentation  and  is  approved  by  the  appropriate  ARC  or 
TSARC. 

Lessons  Learned 

In  the  past  the  FAA  has  not  normally  made  tradeoffs  which  reduce 
NAS-SS-1000  requirements,  eliminated  desired  air  traffic  or 
airway  facilities  functionality,  or  described  systems  that  were 
built  to  commercial  specifications.  In  some  cases  tradeoffs  were 
made  after  contract  award  to  reduce  or  waive  requirements  that 
were  too  difficult  or  costly  to  meet. 

Use  of  NDI  in  communications  systems  has  proven  beneficial  to 
date.  Programs  such  as  high  capacity  voice  recorders, 
transceivers,  modems,  and  microwave  radios  have  been  or  are  in 
the  process  of  being  successfully  acquired  at  relatively  lower 
cost  and  in  much  less  time  that  if  a  full  development  program 
were  undertaken. 

NDI  support  and  life  cycle  issues  must  be  addressed  as  early  as 
possible.  When  NDI  is  used,  especially  COTS,  the  Government 
generally  must  accept  the  contractor's  configuration  management, 
manuals  and  technical  data,  manufacturing  and  quality  control, 
and  logistics  support  structure.  Any  special  requirements,  such 
as  FAA  specification  manuals  or  training,  part  numbering,  or 
special  configuration  control  or  handling  make  a  big  difference 
in  cost.  Commercial  life  cycles  are  also  implicitly  part  of  the 
NDI  bargain,  and  are  generally  much  shorter  than  the  life  cycles 
of  the  equipment  being  replaced.  This  must  be  considered  in 
planning  for  life  cycle  support  or  replacement  of  NDI  systems. 

Responsibilities 

Responsibilities  for  NDI  set  out  in  Order  1810.6  are  generally 
the  same  as  for  any  acquisition,  with  users  responsible  for 
generating  requirements  while  the  ARC  or  other  decision  body  or 
individual  approves  the  acquisition  plans.  Some  specific  areas 
have  some  particular  functions  that  must  be  performed. 

The  program  manager  and  management  team  collect  market 
surveillance  and  investigation  information  to  determine  if 
requirements  can  be  met  with  NDI.  The  program  manager  and  team, 
along  with  other  appropriate  organizations,  must  agree  on  any 
tradeoffs  to  be  made.  Tradeoffs,  such  as  performance,  testing, 
or  logistics  support  that  are  made  must  be  reflected  in 
documentation  and  should  be  agreed  to  by  appropriate  levels  in 
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user,  support,  and.  acquisition  organizations  to  assure  the  traded 
items  do  not  creep  back  in  as  requirements  at  a  later  date. 

Reference  Documents 


The  following  documents  are  the  basis  for  the  material  in  this 
chapter : 

o  FAA  Order  1810.6,  Policy  For  Use  of  Nondevelopmental 
Items  (NDI)  In  FAA  Acquisitions,  November  13,  1992 

o  FAA  Order  1810. IF,  FAA  Acquisition  Policy,  March  19,  1993 

o  Streamlining  Defense  Acquisition  Laws,  Report  of  the 
Acquisition  Law  Advisory  Panel  to  the  United  States 
Congress,  January  1993 

Point  of  Contact  for  Chapter  16  is  Roger  Martino,  ACQ-10, 
202-267-8506. 
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Chapter  17 


Procttrement  Quality  Asautahce 
And  Industrial  Evaluation 


This  chapter  provides  a  reference  to  FAA  NAS  Quality  Assurance 
Policy,  to  the  type  of  quality  assurance  procedures  and  standards 
to  be  used  on  NAS  procurements,  and  describes  the  industrial 
engineering  activities  associated  with  these  procurements. 

Process  Description 

The  Industrial  Division  of  the  Logistics  Service,  ASU-400,  is 
responsible  for  developing  and  implementing  agency  policy, 
standards,  and  procedures  for  the  quality  assurance  programs 
involved  in  the  procurement  of  NAS  systems,  equipment,  and 
material.  The  Division  has  a  headquarters  staff  of  Industrial 
Engineers  and  Industrial  Specialists,  and  a  field  staff  of 
Industrial  Specialists  and  Quality  Assurance  Specialists  (QAS) 
located  throughout  the  United  States.  When  contract 
responsibility  is  assigned  to  a  QAS  he  or  she  is  then  referred  to 
as  the  Quality  Reliability  Officer  (QRO) . 

Order  4630.8,  Quality  Assurance  Policy,  states  that  a  Quality 
Assurance  Program  shall  be  provided  for  and  included  in  the 
documentation  for  the  acquisition  of  all  NAS  systems,  equipment, 
and  material.  This  order  defines  the  responsibilities  of  the 
various  organizations  involved,  and  also  states  the  overall 
objectives  for  having  a  quality  assurance  program. 

Under  the  matrix  management  concept,  the  Industrial  Division  will 
designate  the  Associate  Program  Manager  for  Quality  (APMQ) .  In 
many  cases  this  person  will  also  be  the  QRO  assigned 
responsibility  for  the  contract.  In  some  cases,  however, 
depending  on  the  relationship  and  number  of  contracts  involved  in 
a  particular  program,  the  functions  of  APMQ  and  QRO  may  be 
performed  by  different  personnel.  As  the  APMQ,  the  person 
designated  has  the  responsibility  to  support  the  Program  Manager. 
The  APMQ  is  the  central  point  of  contact  for  the  Division  on  all 
QA  matters.  As  the  QRO,  the  person  designated  has  the 
responsibility  to  provide  on-site  QRO  support  at  the  contractors' 
facilities  under  the  authority  delegated  by  the  Contracting 
Officer.  The  QRO  assures  that  the  contractor  adheres  to  contract 
quality  assurance  requirements,  and  is  authorized  to  accept  or 
reject  systems,  equipment,  and  material  in  accordance  with  the 
contract  requirements. 
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The  Industrial  Division  has  implemented  a  program  that  is 
referred  to  as  the  "Certification  Program".  This  program  is 
described  in  FAA  Order  4453.2  and  Advisory  Circular  00-41.  The 
Certification  Program  is  only  invoked  on  major  procurements  when 
FAA-STD-016  is  used.  Under  this  program,  potential  contractors 
submit  a  "Quality  Control  System  Plan  (QCSP) "  as  part  of  their 
proposal  submission.  This  plan  is  thoroughly  reviewed  by  the 
Industrial  Division,  deficiencies  are  negotiated  and  resolved, 
and  the  final  approved  plan  is  incorporated,  at  contract  award, 
into  the  contract.  After  contract  award,  and  after  the  in-plant 
QRO  has  made  a  determination  that  the  QCSP  has  been  acceptably 
implemented,  the  successful  contractor  is  presented  with  a 
certificate  that  attests  to  the  approved  quality  control  system. 
The  philosophy  behind  this  program,  which  has  proved  to  be  very 
successful,  is  that  it  is  the  contractor's  responsibility  to 
perform  the  QA  function,  and  it  is  the  Government's 
responsibility  to  verify  that  this  function  is  being  performed. 
The  use  of  a  certificate,  which  is  usually  presented  to  the 
company  by  a  senior  FAA  official  in  a  formal  presentation  with 
company  personnel  present,  helps  to  bring  home  to  the  company  the 
importance  the  FAA  places  on  quality  assurance,  and  helps  serve 
as  a  motivating  factor  to  company  personnel  in  the  performance  of 
the  contract . 

Headquarters  Activities 

The  headquarters  staff  of  the  Industrial  Division  provides 
several  services,  many  of  which  occur  during  the  "before  award" 
phase  of  a  procurement. 

Contractor  evaluations  are  normally  performed  by  the  Industrial 
Engineers.  The  two  most  common  types  of  evaluations  are  Preaward 
Surveys  and  Production  Capacity  Evaluations.  A  preaward  survey 
is  usually  requested  by  the  Contracting  Officer  (CO) ,  although 
the  Program  Office  can  request  it  through  the  CO.  The  purpose  of 
this  survey  is  to  determine  that  the  potential  contractor  has  the 
necessary  capabilities  to  satisfactorily  perform  the  proposed 
contract.  The  normal  areas  investigated  include  Technical 
Capability,  Production  Capacity,  and  Quality  Assurance.  A 
representative  of  the  Program  Office  or  Technical  Office  will  be 
requested  to  be  part  of  the  preaward  team  for  the  purpose  of 
performing  the  "Technical"  portion  of  the  survey. 

Production  Capacity  Evaluations  are  normally  performed  after 
contract  award,  at  the  request  of  either  the  CO  or  the  Program^ 
Office,  and  are  usually  performed  when  difficulties  arise,  or  it 
is  desired  to  get  an  independent  "look"  at  the  contract  status 
and  progress . 

In  order  to  assure  that  the  proper  QA  requirements  are  used,  the 
Division  reviews  various  procurement  documents.  These  include 
such  documents  as  procurement  requests  (PRs) ,  specifications, 
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statements  of  work  (SOWs) ,  and  solicitations.  On  major 
procurements,  a  representative  of  the  Division  will  be  a  member 
of  the  Source  Evaluation  Board  (SEB) .  While  the  primary  activity 
of  the  Division  representative  in  these  functions  is  QA,  a 
secondary  role  is  to  provide,  when  requested,  Industrial/ 
Manufacturing  Engineering  input,  and  to  act  as  a  technical 
liaison  between  the  contracts  and  the  technical  organizations. 

During  the  proposal  evaluation  phase  of  a  procurement,  when  FAA- 
STD-016  and  the  Certification  Program  is  used,  a  member  of  the 
Division,  usually  the  QA  member  of  the  SEB,  will  act  as  the  QA 
review  team  chairperson.  He  or  she  will  be  responsible  for 
reviewing  the  contractor  submitted  QCSP,  negotiating  any 
deficiencies  with  the  contractor,  and  providing  final  approval  of 
the  plan.  Additionally,  this  same  person  would  also  perform  a 
similar  function  in  reviewing/approving  the  Computer  Software 
Quality  Program  Plan  (CSQPP)  submitted  in  response  to  FAA-STD-018 
when  this  standard  has  been  made  a  requirement  of  the  contract. 

After  contract  award,  a  Quality  Reliability  Officer  (QRO)  will  be 
assigned  by  the  Quality  Assurance  Branch.  This  is  accomplished 
by  the  Contracting  Officer  sending  two  copies  of  the  contract  to 
the  branch.  Upon  receipt  of  the  contract,  branch  personnel  will 
assign  a  QRO  and  provide  the  Contracting  Officer  the  necessary 
documentation  for  the  formal  Letter  of  Delegation.  While  the  QRO 
is  assigned  to  the  contract  by  the  Division,  his  or  her  authority 
on  the  contract  actually  comes  from  the  CO  as  stated  in  the 
Letter  of  Delegation  that  is  sent  to  the  contractor. 

In  addition  to  the  above,  the  Division  is  also  responsible  for 
implementing  the  guidelines  and  procedures  for  the  acquisition  of 
reprocurement  data.  The  subject  of  reprocurement  data,  and  the 
FAA  policy,  is  addressed  in  FAA  Order  4405.15.  The  Division  has 
the  responsibility  to  review,  and  approve/disapprove  all 
headquarters  requirements  and  maintenance  organizations 
recommendations  regarding  the  acquisition  of  reprocurement  data, 
and  to  maintain  an  index  of  reprocurement  data  received. 

Field  QA  Activities 

After  contract  award,  a  QRO  will  be  assigned  to  the  contract  as 
described  above.  The  QRO  may  also  be  the  APMQ  for  that  program, 
or  a  different  person  may  be  the  APMQ  depending  on  the 
relationship  and  number  of  contracts  within  a  Program  Office. 

The  main  functions  of  the  QRO  are  to  verify  the  acceptability  of 
the  contractors  QA  system,  perform  inspections  and  test 
witnessing,  and  to  accept  or  reject  items  submitted  by  the 
contractor  in  accordance  with  the  terms  and  conditions  of  the 
contract.  If  final  acceptance  is  at  destination  then  the  QRO 
will  perform  a  "preliminary"  inspection  and  acceptance  function. 
As  the  APMQ,  the  QRO  will  support  the  Program  Office  in 
accordance  with  the  Program  Directive,  that  is  agreed  to  by  the 
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Program  Office  and  the  Division,  and  be  the  central  point  of 
contact  for  the  Division  on  all  QA  matters. 

In  addition  to  the  in-plant  QA  functions,  field  activities  also 
include  contract  administration  activities  such  as  monitoring 
contractors  progress,  evaluating  and  commenting  on  progress 
payment  submissions,  and  issuing  periodic  QRO  progress  reports. 

A  production  surveillance  function  is  also  performed  on  major 
contracts  by  the  field  Industrial  Specialists. 

FAA  Quality  Standards  and  Their  Use 

Part  46  of  the  Federal  Acquisition  Regulation  (FAR)  specifies  the 
type  of  QA  requirements  to  be  used  on  various  procurements. 

Almost  all  FAA  procurement  for  supplies  will  at  least  use  FAR 
clause  52.246-2.  If  a  procurement  involves  complex  and/or 
critical  requirements,  then  the  FAR  prescribes  that  a  "higher 
level  contract  quality  requirement"  be  used.  In  the  FAA,  there 
are  three  higher  level  QA  requirements  that  are  used.  These  are 
FAA-STD-013,  FAA-STD-016,  and  FAA-STD-018.  Following  is  a  brief 
description  of  each,  and  the  conditions  for  their  appropriate 
use . 

o  FAA-STD-013  specifies  requirements  for  an  inspection/QC 
system.  This  standard  would  be  used  on  procurements 
that  are  of  an  equipment  or  small  system  nature,  rather 
than  procurements  that  are  major  systems.  FAA-STD-013 
is  essentially  a  "hardware"  oriented  standard,  but  it 
does  include  some  software  QA  requirements.  This 
standard  would  also  be  used  on  procurements  that  are  for 
Non-Developmental  Items  (NDI) ,  although  some  NDI 
procurements  that  are  literally  "commercial-off-the- 
shelf"  (COTS)  would  not  use  this  standard,  but  would 
instead  just  invoke  FAR  Clause  52.246-2. 

o  FAA-STD-016  specifies  more  requirements  than  FAA-STD- 
013,  and  is  used  on  procurements  that  are  for  major 
systems.  The  use  of  FAA-STD-016  invokes  the  FAA 
Certification  Program,  which  is  described  in  FAA  Order 
4453.2.  As  specified  in  this  order,  the  certification 
program  and  FAA-STD-016  would  be  used  when  the  item(s) 
to  be  procured  is  of  sufficient  complexity,  and  the 
total  contract  expenditure  is  expected  to  be  $10  million 
or  more.  FAA-STD-016  is  essentially  a  "hardware" 
oriented  standard,  but  it  does  include  some  software  QA 
requirements . 

o  FAA-STD-018  specifies  requirements  pertaining  to 

software  QA.  The  use  of  this  standard  is  prescribed  in 
FAA  Order  4630.9.  It  can  be  used  alone,  or  in 
conjunction  with  either  FAA— STD— 013  or  FAA— STD— 016. 

This  standard  is  used  when  the  procurement  involves  a 
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software  development  period  of  at  least  one  year,  and 
the  software  is  coraplex/critical  requiring  high 
reliability  and  maintainability. 

In  addition  to  the  above  standards,  section  E  of  any 
solicitation/contract  will  contain  the  requirements  with  respect 
to  inspection  and  acceptance.  Standard  "Section  E"  clauses  have 
been  developed  for  any  combination  of  QA  standards  used.  It  is 
in  this  section  of  the  contract  that  the  FAR  clause  or  higher 
level  quality  requirements  is  specified.  This  section  of  the 
contract  will  also  contain  references  to  the  QRO  and  his/her 
duties.  In  a  solicitation,  when  FAA-STD-016  or  FAA-STD-018  is 
specified,  the  requirements  with  respect  to  the  QCSP  or  CSQPP 
will  be  given  in  section  L  of  the  RFP  along  with  the  other 
proposal  requirements. 

Lessons  Learned 

Significant  problems  occur  when  an  incorrect  QA  standard  is  used, 
or  when  no  QA  standard  is  specified.  Use  of  an  incorrect 
standard  can  cause  unnecessary  costs  to  be  incurred  by  the 
contractor  and  the  Government,  and  the  lack  of  a  QA  standard  can 
lead  to  poor  quality  and  its'  associated  costs.  It  is  important 
that  the  Program  Office  coordinate  with  ASU-400,  early  in  the 
programs  development,  as  to  the  correct  standard (s)  to  be  used. 

A  procurement  for  NDI  or  COTS  does  not  automatically  mean  that  no 
"higher  level"  QA  standard  is  needed.  Any  NDI  or  COTS 
procurement  should  be  coordinated  with  ASU-400  as  to  the 
appropriate  type  of  QA  standard  to  be  used. 

While  the  APMQ  is  a  member  of  the  Program  Management  team,  it 
must  be  realized  that  he  or  she,  when  acting  also  as  the  QRO,  is 
legally  bound  to  perform  his  or  her  duties,  and  to  accept  or 
reject  contract  items  in  accordance  with  contract  requirements. 
Any  deviation  or  waiver  to  the  contract  requirements  that  the 
Program  Office  plans  to  approve,  must  be  formally  incorporated 
into  the  contract  before  the  QRO  can  accept  the  item. 

Responsibilities 

The  Program  Manager  is  responsible  for  including  appropriate 
Quality  Assurance  provisions  in  all  contract  documents  as  stated 
in  FAA  Order  4630.8,  Quality  Assurance  Policy. 

The  Industrial  Division  is  responsible  for  providing  and 
assigning  the  necessary  APMQ/QRO  and  other  support  to  the  Program 
Office,  as  required. 
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Contacts 


The  following  groups  can  be  contacted  for  additional  information 
in  the  areas  indicated: 

o  Contractor  Evaluations,  and  any  "before  award" 
activities,  ASU-410,  202-267-8270 

o  APMQ/QRO  assignments,  and  any  "after  award"  activities, 
ASU-420,  202-267-8908 

o  Copies  of /Information  regarding  FAA  QA  Standards  and 
Reprocurement  Data,  ASU-430,  202-267-8270 

Reference  Documents 

The  following  documents  are  the  basis  for  the  guidelines 
presented : 

o  FAA  Order  4630.8,  Quality  Assurance  Policy 

o  FAA  Order  4453. lA,  Quality  Assurance  of  Material 
Procured  by  the  FAA 

o  FAA  Order  4453. 2B,  FAA  Quality  Control  System 
Certification  Program 

o  FAA  Order  4630. 9A,  FAA  Computer  Software  Quality  Program 
Requirements 

o  FAA  Order  4405.15,  Reprocurement  Data  Acquisition  Policy 

o  FAA-STD-013,  Quality  Control  Program  Requirements 

o  FAA-STD-016A,  Quality  Control  System  Requirements 

o  FAA-STD-018,  Computer  Software  Quality  Program 
Requirements 

o  Federal  Acquisition  Regulation,  Part  46,  Quality 
Assurance 

o  Advisory  Circular  00-41,  FAA  Quality  Control  System 
Certification  Program 

o  Advisory  Circular  00-53,  FAA  Computer  Software  Quality 
Program 

Point  of  Contact  for  Chapter  17  is  Paul  Przedpelski,  ASU-400, 
202-267-8904 . 
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Chapter  18 


Pjcoduction  Engineering  Management 


This  chapter  provides  a  quick  reference  for  Production 
Engineering  Management  (PEM)  in  the  National  Airspace  System. 

Process  Description 

PEM  is  the  process  used  to  ensure  that  effective  resources  and 
design  techniques  are  being  used  to  produce  the  required  products 
in  a  timely  manner  in  order  to  meet  the  specified  requirements 
for  performance,  quality  and  cost.  Early  detection  and  rapid 
reporting  of  existing  and  potential  production  problems  is 
essential  to  program  success.  Some  of  the  areas  to  be 
investigated  specific  to  PEM  are  capacity  resource  analysis, 
producibility  analysis,  production  planning,  production 
engineering,  tooling,  equipment,  manufacturing  processes  and 
program  specification  adherence. 

Production  is  a  system  of  interrelated  activities  and  operations 
involving  the  design,  materials  selection,  planning  manufacture, 
quality  assurance,  and  management  of  discrete  and  durable  goods. 
The  world  of  production  is  far  different  from  that  of  prototype 
or  development.  It  deals  with  the  mass  producing  of  products  on 
hard  tooling;  whereas  engineering  development  deals  with  very 
small  quantities  generally  produced  on  soft  tooling  in  a 
laboratory  environment  utilizing  high-priced  labor  categories 
(i.e.,  engineers  and  skilled  technicians) .  Articles  that  can  be 
satisfactorily  developed  and  tested  in  laboratory  conditions,  on 
what  is  often  handmade  tooling  and  test  fixtures,  do  not  lend 
themselves  to  mass  production  processes.  These  changed  processes 
often  introduced  changes  in  the  operating  characteristics  of  the 
article  or  created  the  potential  that  the  article  in  fact  cannot 
be  mass  produced.  These  problems  will  lead  to  significant  rework 
and  additional  testing  which  will  impact  schedule  and  cost. 

The  transition  between  the  development  and  production  phases,  and 
the  implementation  of  proven  production  techniques  on  the 
manufacturing  floor  is  critical  to  program  success.  An 
engineering  change  introduced  during  the  development  phase 
generally  will  have  little  impact  on  system  schedule  and  cost. 
During  production,  however,  that  same  change  could  devastate  the 
program  since  its  impact  will  affect  so  many  different  areas. 
Effective  production  management  is  a  valuable  asset  to  the  FAA  in 
evaluating  the  producibility  of  the  design  and  impact  of  design 
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changes  in  both  the  development  and  production  phases  of  an 
acquisition , 

Transition  from  the  development  to  the  production  phase  and 
success  in  the  ensuing  production  operations  require  the 
implementation  of  sound  techniques  and  practices  on  the  factory 
floor.  Recent  Government  studies  reflect  that  90  percent  of 
modern  electronic  system  failures  were  determined  to  be 
production-related . 

Significant  causes  cited  for  this  include  the  following: 

o  Engineering  changes  not  implemented  into  production 
documentation 

o  Improper  tooling 

o  Excessive  hardware  rework  and  repairs  degrading  the 
quality  of  the  equipment 

o  Factory  floor  capacity  exceeded  in  an  attempt  to  regain 
the  program  schedule 

o  Engineering  documentation  not  understood  at  the  factory 
level 

o  Lack  of  early  production  involvement  in  the  transition 
process 

o  Improper  or  inadequate  level  of  staffing 
o  Poorly  trained  production  personnel 

o  Key  personnel  not  available  with  the  required  skills 

o  Key  personnel  being  transferred  among  different  programs 
without  adequate  replacement 

o  Factory  floor  not  working  to  detailed  milestones 
developed  to  achieve  overall  project  objectives 

Problems  of  this  nature  can  be  detected  and  reported,  and 
solutions  recommended  to  the  FAA  program  office  through  the 
utilization  of  the  PEM  function.  Onsite  surveillance  of  a 
contractor' s  production  and  manufacturing  operations  is  an 
excellent  means  of  detecting  variances  from  production  plans  and 
system  schedules,  and  from  the  use  of  proven,  effective 
manufacturing  processes . 
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The  PEM  function  has  the  following  goals: 

o  To  enhance  the  manufacturing  management  process 

o  To  improve  system  effectiveness 

o  To  ensure  product  quality 

Enhance  the  Manufacturing  Management  Process 

Effective  PEM  can  enhance  both  productivity  and  manufacturing 
management  through  a  comprehensive  surveillance  of  the  following 
contractor  tasks:  production  and  manufacturing  strategies  and 
processes;  use  of  state-of-the-art,  proven  technologies;  use  of 
the  engineering  discipline;  daily  management  of  engineering/ 
design  change  notices;  and  implementation,  on  the  shop  floor,  of 
the  principles  of  total  quality  control  management. 

Improve  System  Effectiveness 

Problems  involving  production  and  manufacturing  areas  will 
negatively  impact  both  program  cost  and  schedule  at  a  time  in  the 
product  life  cycle  when  all  schedule  and  cost  slack  has  usually 
been  consumed  by  the  design  and  system  development  phases. 
Problems  at  this  phase  of  a  program  almost  always  represent  a 
direct  probable  delay  in  product  delivery. 

Some  of  these  production  areas  include  the  following: 

o  Production  control 

o  Manufacturing  processes  and  methodology 
o  Material  control  and  handling 
o  Facilities  layout 

o  Capacity  (especially  when  other  programs  become  the 
contractor's  priority) 

o  Use  of  special  test  equipment,  tooling,  fixtures  and/or 
jigs  that  will  be  a  challenge  to  reproduce  in  the  field 

o  Random  parts  substitution 

o  Ineffective  management  of  essential  labor  skills 

o  Movement  of  key  personnel  to  react  to  other  contract 
problems 
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Ensure  Product  Quality 

The  quality  of  a  product  tends  to  diminish  and  a  well-engineered 
system  goes  on  a  self-destructive  course  in  production  phase  of  a 
program  when  the  following  occurs: 

o  Less  than  needed  skill  is  used 

o  Testing  is  intentionally  reduced  to  recover  schedule 

o  Substandard  parts  are  used  as  substitutes  to  take 
advantage  of  better  lead  times  and  to  lower  the 
manufacturer's  costs 

o  Tools  are  used  beyond  their  projected  useful  life 

o  Personnel  is  not  rotated  and  get  complacent  and  careless 
doing  the  same  operation  over  and  over 

o  Poor  rework  procedures  are  used 

o  Organizational  stress  is  felt  on  the  shop  floor 

Effective  PEM  will  aid  the  FAA  by  not  letting  these  areas  of 
concern  go  unnoticed.  PEM  will  track  key  milestones,  take  key 
productivity  measurements  and  monitor  the  contractor' s  use  of 
proven  manufacturing/production  techniques  (back-up  tooling,  tool 
calibration,  cross-training,  job  rotation,  use  of  a  skilled 
assembler  for  rework  operations,  etc.)  to  help  ensure  the  FAA 
that  a  quality  product  is  being  produced  each  and  every  time. 

It  must  be  clearly  understood  that  PEM  and  the  QRO  have  separate 
and  distinct  functions. 

The  PEM,  composed  of  System  Engineering  and  Integration 
Contractor  personnel,  initiates  its  activities  early  in  the 
acquisition  life-cycle  process  and  continues  its  support 
throughout  the  Request  for  Proposal  (RFP) ,  evaluation  and 
acquisition,  and  production  and  testing  phases.  PEM  monitors  and 
verifies  that  the  FAA  contractors,  during  both  the  proposal 
evaluation  and  contract  award  phases,  are  complying  with  all  the 
production-related  requirements  of  the  RFP  and  contract.  PEM 
also  monitors  each  critical  component  of  the  contractor's 
production  plan,  thereby  allowing  early  identification  of 
potential  problems,  and  it  provides  a  reasonable  timeframe  for 
implementing  proposed  solutions.  This  effort  will  mitigate  any 
negative  effect  on  quality,  cost,  and  schedule. 

The  QRO,  a  Government  employee,  provides  onsite  monitoring  of  the 
contractor's  day-to-day  activities  to  ensure  compliance  with 
applicable  quality  standards  and  contract  requirements.  The  QRO 
is  also  responsible  for  accepting  the  final  product  from  the 
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contractor.  These  functions  are  normally  conducted  after  the 
contract  has  been  awarded. 

The  PEM  and  the  QRO  interface  during  the  transition  from 
development  to  production.  At  this  point  the  PEM  assesses  the 
risk  of  the  transition,  identifies  deficiencies,  and  recommends 
corrective  actions.  The  QRO  works  with  the  contractor  to  develop 
and  implement  corrective  action. 

Contacts 

The  following  division  can  be  contacted  for  additional 
information  on  production  engineering  management: 

o  SEI  contractor  Production  Engineering  Management  Group, 
202-646-5358 

Reference  Documents 

The  following  documents  are  the  basis  for  the  guidelines 
presented: 

o  Air  Force  Systems  Command  Regulation  84-2,  Production 
Readiness  Review 

o  DOD-DIR-4245 . 6,  Defense  Production  Management 

o  DOD-DIR-5000 . 1 ,  Major  Systems  Acquisitions 

o  DOD-DIR-5000 . 39,  Acquisition  and  Management  of 

Integrated  Logistics  Support  for  Systems  and  Equipment 

o  DOD-DIR-5010 . 19,  DOD  Configuration  Management  Program 

o  DOD-INST-5000 . 2M,  Major  Systems  Acquisition  Procedures 

o  DOD-INST-5000 . 38 ,  Production  Readiness  Reviews 

o  DOD-INST-7000 . 2,  Performance  Measurement  for  Selected 
Acquisitions 

o  DOD-INST-7000 . 10,  Contract  Cost  Performance,  Funds 
Status  and  Cost/Schedule  Status  Reports 

o  DOD-STD-480A,  Configuration  Control 

o  DOD-STD-481A,  Configuration  Control  Engineering  Changes 

o  DOD-STD-1686,  Electrostatic  Discharge  Control  Program 

o  FAA-G-2100F,  Electronic  Equipment,  General  Requirements 
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o  FAA-STD-016A,  Quality  Control  System  Requirements 

o  FAA-STD-021A,  Configuration  Management 

o  .MIL-STD-965A,  Parts  Control  Program 

o  MIL-STD-152 IB,  Technical  Reviews  and  Audits  for  Systems, 
Equipment,  and  Computer  Programs 

o  MIL-STD-2000,  Standard  Requirements  for  Soldered 

Electrical  and  Electronic  Assemblies 

Point  of  Contact  for  Chapter  18  is  Paul  Przedpelski,  ASU-400, 
202-267-8904. 
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Chapter  19 


This  chapter  describes  the  operation  of  the  Deployment  Readiness 
Review  (DRR) . 

DRR  Process  Description 

The  DRR  process  is  a  structured  assessment  of  the  subsystems/ 
equipment  acquired  under  the  Aviation  System  CIP,  and  selected 
R&D,  regional  or  headquarters  Operations  funded  projects.  This 
is  done  to  determine  if  they  are  ready  to  be  deployed  into  the 
National  Airspace  System  (NAS) ,  and  whether  the  FAA  is  ready  to 
receive,  utilize,  and  support  them. 

The  process  utilizes  a  team  of  experts  to  develop  a  DRR  checklist 
which  addresses  the  concerns  of  the  program  office,  ABU,  ALR, 

AAT,  ACT,  AHR,  AMC,  ALM,  ANS,  AOP,  regions,  etc.,  and  is  updated 
periodically.  It  should  start  about  16  months  prior  to  delivery 
to  the  T&E  site  to  fully  realize  its  value. 

This  structured  assessment  is  a  management  tool  used  to  identify, 
track,  monitor,  and  control  the  critical  and  noncritical  items 
until  completion.  The  critical  items  must  be  resolved  prior  to 
deployment;  the  noncritical  items  need  firm  action  plans  in  place 
with  completion  dates,  before  a  deployment  decision  is  rendered. 

Lessons  Learned 

Use  the  DRR  process  and  checklist  early  in  the  acquisition 
process.  This  avoids  problems  later  on  and  makes  it  easier  to 
prepare  the  PR  and  solicitation  packages.  It  also  expedites  the 
deployment  process. 

Start  the  DRR  process  early  in  the  development  cycle  so  that  all 
members  of  the  team  are  on  track  and  working  the  issues  that  have 
to  be  solved. 

Resolve  critical  DRR  items  as  soon  as  possible  to  avoid  problems 
at  the  start  of  deployment. 

Using  the  DRR  checklist  in  the  procurement  planning  phase  will 
ensure  that  deployment  considerations  are  addressed  in  the 
program , 
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Responsibilities 

The  major  responsibility  of  the  PM  in  the  DRR  process  is  to 
conform  to,  and  apply  the  provisions  of  Order  1800.63,  NAS 
Deployment  Readiness  Review  (DRR)  Program,  in  the  following  ways: 

o  Ensure  that  the  DRR  checklist  is  used  for  a  variety  of 
pre-DRR  events  as  part  of  the  responsibilities, 
authority  and  accountability  for  a  system  acquisition 

o  Initiate,  conduct,  and  complete  a  thorough  and  objective 
project  DRR  including  fulfilling  DRR  team  leader 
responsibilities 

o  Establish  and  maintain  currency  of  the  Master  Scheduling 
System  (MSS)  milestones  that  are  key  to  scheduling 
events  governing  the  DRR  process 

o  Ensure  prompt  closure  of  the  DRR  checklist  open  items 

assigned  to  the  project  office  in  accordance  with  action 
plans  and  established  closure  dates 

o  Conduct  a  project  review  and  report  the  results,  citing 
all  remaining  deployment  critical  and  non-deployment 
critical  issues  in  a  DRR  Report  to  the  Associate 
Administrator  for  Airway  Facilities 

The  Airway  Facilities  DRR  Program  Manager,  ALM-200A  (Guy  Hawkes) , 
is  responsible  for  the  following; 

o  Manage  the  DRR  program  as  defined  in  Order  1800.63 

o  Serve  as  an  expert  resource  on  the  DRR  process  and 
support  the  Program  Manager  in  meeting  his/her  DRR 
responsibilities 

o  Manage  DRR  support  functions,  thereby  ensuring 

timeliness  of  DRR  events  such  as  reports,  integrity  of 
project  reviews,  establishment  and  update  of  project 
checklists,  data  bases,  clearance  of  issues,  final 
closure  of  projects,  etc. 

o  Advise  the  Associate  Administrator  for  Airway  Facilities 
on  DRR  program  matters 
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The  DRR  Team  Members  are  responsible  for  the  following: 

o  Perform  an  objective  assessment  of  project  deployment 
readiness  as  defined  in  Order  1800.63 

o  Provide  assistance  to  the  PM  as  part  of  their 

organization's  functional  responsibility,  by  speaking 
for  all  elements  involved  in  the  project 

o  Serve  as  expert  resource  to  the  team  to  aid  in  the 
identification  of  issues  and  appropriate  action 
office (s)  for  resolution 

o  Review  the  annotated  project  DRR  checklist  to  ensure 

completeness  and  accuracy  of  all  identified  issues,  and 
ensure  that  all  identified  action  plans  support  closure 

o  Facilitate  closure  of  issues  within  the  purview  of  their 
parent  organization 

o  Review  the  DRR  Report  to  ensure  it  states  the  identified 
concerns  correctly 

o  Prepare  the  parent  organization's  representative  for 

participation  in  the  DRR  Executive  Committee  (EXCOM)  for 
that  project 

DRR  Focal  Points 

DRR  focal  points  are  designated  by  the  parent  organizations  (AMC, 
ACT,  regions,  AVN,  etc.)  to  serve  as  ongoing  liaison  with  DRR 
program  management  for  all  activities,  and  their  responsibilities 
include  the  following: 

o  Manage  DRR  activities  within  their  parent  organization 

o  Provide  liaison  between  the  organization  and  the  DRR 
program  management 

o  Support  their  organization's  representative  to  the  DRR 
EXCOM 

The  DRR  Executive  Committee 

The  DRR  EXCOM  is  comprised  of  executive-level  FAA  and  support 
contractor  personnel.  Their  responsibility  is  to  review  the  DRR 
Report  and  provide  advice  and  counsel  to  the  Chairman  (the 
Associate  Administrator  of  Airway  Facilities)  who  makes  the 
deployment  decision  for  each  individual  project. 
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Contacts 


The  DRR  Program  Manager  can  be  contacted  for  additional 
information  on  the  DRR  process: 

o  Guy  Hawkes,  ALM-200A,  202-267-7489,  202-267-5632  (fax) 

Reference  Doc^aments 

The  following  documents  are  the  basis  for  the  guidelines 
presented: 

o  Order  1800.63,  National  Airspace  System  (NAS)  Deployment 
Readiness  Review  (DRR)  Program 

o  DRR  checklists  are  available  from  ALM-200A,  the  DRR 
Support  Contractor  -  NISC,  and  the  DRR  Electronic 
Bulletin  Board  System  (EBBS) 

Point  of  Contact  for  Chapter  19  is  Guy  Hawkes,  ALM-200A, 
202-267-7489 . 
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Chapter  20 


This  chapter  presents  information  regarding  the  agency's 
statutory  and  contractual  obligations  to  deal  with  employees  who 
are  represented  by  labor  organizations. 

Process  Description 

Although  system  capacity  and  safety  are  the  primary  concerns  in 
acquiring  major  systems,  PMs  must  also  consider  the  employees  who 
will  operate  and  maintain  these  new  systems.  The  majority  of 
employees  who  operate  and  maintain  the  air  traffic  system  are 
covered  by  five  national  unions.  Any  employee  input  must  be 
obtained  from  these  exclusive  representatives: 

o  The  National  Air  Traffic  Controllers  Association  (NATCA) 
represents  all  GS-2152  air  traffic  control  specialists 
located  at  terminal  and  enroute  facilities 

o  The  Professional  Airways  Systems  Specialists  -  Airway 
Facilities  Unit  (PASS/AF)  represents  the  employees  of 
the  Regional  Airway  Facilities  Divisions 

o  The  Professional  Airways  Systems  Specialists  -  Flight 
Standards  Unit  (PASS/FS)  represents  Flight  Standards 
employees  world-wide 

o  The  National  Association  of  Air  Traffic  Specialists 

(NAATS)  represents  air  traffic  control  specialists  at 
flight  service  stations 

o  The  National  Association  of  Government  Employees  (NAGE) 
represents  air  traffic  assistants 

The  agency  has  negotiated  national  agreements  with  four  unions: 
NATCA,  PASS/AF,  PASS/FS,  and  NAATS.  A  contract  has  not  yet  been 
negotiated  with  NAGE. 

The  Administrator  has  delegated  to  the  Office  of  Labor  and 
Employee  Relations  (ALR)  the  responsibility:  to  deal  with  the 
national  labor  organizations,  to  negotiate  and  administer  the 
national  agreements,  to  negotiate  and  approve  mid—term 
agreements,  and  to  conduct  daily  labor-management  relations 
contacts  on  behalf  of  FAA  management.  Centralization  of  labor 
relations  activities  ensures  consistent  interpretation  and 


20-1 


application  of  law,  rules,  regulations,  agency  policy  and 
national  agreements. 

Determining  Impact  on  Bargaining  Unit  Employees 

To  ensure  that  PMs  and  the  appropriate  management  officials  have 
an  awareness  of  the  effect  of  their  decisions  in  acquiring  new 
systems,  ALR-100  has  instituted  a  process  which  is  included  as  an 
issue  item  on  the  Deployment  Readiness  Review  (DRR)  Checklist  for 
each  system. 

This  process  requires  that  the  PM  contact  the  relevant 
headquarters  management  office  (AFZ-300,  ATZ-2,  or  AFS-6)  to 
determine  the  impact  of  a  particular  system  on  bargaining  unit 
employees.  The  first  issue  review  will  alert  management  to 
impact  issues  in  the  areas  of  contractor  maintenance,  training, 
certification,  etc.,  before  they  are  finalized,  and  to  what 
extent  they  could  affect  staffing  and  employee  grades.  A  copy  of 
the  checklist  used  to  determine  impact  on  employees  is  included 
as  Figure  20.1.  This  early  review  will  focus  PMs  and  the 
operating  management  officials  on  potential  problems  that  could 
arise  in  the  labor/management  area  and  prevent  unforseen  delays 
in  deployment . 

The  second  requirement  is  that  as  the  time  for  deployment 
approaches,  any  impact  on  the  bargaining  unit  employees  must  be 
communicated  to  the  national  unions  in  order  that  they  may  decide 
whether  or  not  to  invoke  negotiations.  The  time  frames  for 
notification  vary  for  each  union.  For  example,  the  NATCA 
agreement  requires  notification  and  involvement  in  work  groups, 
30-day  notification  prior  to  field  evaluation  and  OT&E,  and 
notification  and  bargaining  prior  to  the  Deployment  Readiness 
Review  Executive  Committee  Meeting  (EXCOM) . 

Obtaining  Input  from  Unionized  Employees 

Under  the  Federal  Labor  Management  Relations  Statute,  the  agency 
must  negotiate  any  adverse  impact  on  bargaining  unit  employees 
prior  to  implementing  changes  to  personnel  policies,  practices, 
or  other  conditions  of  employment.  To  bypass  the  union  and  deal 
directly  with  the  employees  constitutes  an  unfair  labor  practice. 

PMs  may  require  employee  input  on  the  development  and 
implementation  of  a  system  through  various  means,  such  as  work 
groups,  surveys,  site  visits,  and  testing  and  simulation  of 
equipment.  Bargaining  unit  employees  participation  in  these 
endeavors  must  be  coordinated  with  ALR-100,  ATZ-2,  AFZ-300,  or 
AFS-6  at  Headquarters.  The  PM  shall  give  ALR-100  an  advance  copy 
of  any  survey  instrument  for  solicitation  of  bargaining  unit 
employee  input.  The  PM  shall  also  identify  the  desired 
qualifications  of  the  employees  participating  in  workgroups  such 
as  the  experience  level  required,  the  dates  of  involvement, 
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travel  requirements,  etc.  In  the  case  of  NATCA,  once  this  is 
done,  ALR-100  will  communicate  these  requirements  to  the  union 
and  obtain  a  designated  representative  of  the  Union  to 
participate  in  the  work  group.  Sufficient  lead  time  should  be 
allowed  in  requesting  union  designees  to  reorganize  their  work 
schedules  to  avoid  overtime  costs . 

Negotiating  Before  Deploying  Systems 

The  DRR  Checklist  requires  that  PMs  provide  90-day  advance 
notification  of  deployment  to  ALR-100  to  ensure  that  the  agency 
meets  its  bargaining  obligations  with  the  unions  in  accordance 
with  existing  contract  provisions.  The  PM  should  work  with  the 
Project's  focal  points  in  Air  Traffic,  Airway  Facilities,  and 
Flight  Standards  to  determine  the  impact  of  the  particular  NAS 
system  on  bargaining  unit  employees.  At  least  90  days  before  the 
EXCOM,  the  PM  should  submit  an  executive  summary  and  checklist 
using  the  outline  in  Figures  20.1  and  20.2  as  a  guide. 

Upon  receipt  of  any  bargaining  proposals,  ALR-lOO  will  notify  the 
appropriate  PM,  through  the  labor  relations  points  of  contact  in 
Air  Traffic,  Airway  Facilities,  and/or  Flight  Standards. 
Negotiations  are  normally  limited  to  the  impact  technological  or 
procedural  changes  will  have  on  bargaining  unit  employees.  There 
is  no  obligation  to  bargain  on  the  specifications  of  the  system 
or  on  management's  decision  to  proceed  with  the  deployment. 

Even  though  a  project  may  have  received  a  waiver  or  exception 
from  the  DRR  process,  the  obligation  to  inform  and  negotiate  with 
the  unions  will  still  apply. 

Responsibilities 

The  Administrator  has  delegated  to  the  Director  of  Labor  and 
Employee  Relations,  ALR-1,  the  approval  of  collective  bargaining 
agreements  on  the  impact  and  implementation  of  NAS  systems. 

The  Director  of  Labor  and  Employee  Relations  administers  the 
overall  labor-management  relations  program  in  FAA  which  includes 
the  following; 

o  Ensuring  that  the  labor  organizations'  views  on  agency 
personnel,  policies,  and  practices  affecting  working 
conditions,  when  appropriate  or  required,  are  solicited 
and  made  available  to  agency  management  officials 

o  Representing  the  agency  in  discussions  and  negotiations 
with  national  officials  of  labor  organizations 

The  PM  is  responsible  for  providing  the  necessary  information  to 
the  Director  of  Labor  and  Employee  Relations  in  a  timely  manner 
so  that  the  Director  can  notify  the  national  unions  before  NAS 
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systems  are  deployed.  The  PM  is  also  responsible  for  informing 
ALR-1  before  conducting  surveys  of  bargaining  unit  employees  and 
in  soliciting  employees  for  tests,  demonstrations,  and 
development  of  systems  or  subsystems . 

Contacts 

The  following  branch  or  divisions  can  be  contacted  for  additional 
information  in  the  areas  indicated: 

o  Airway  Facilities  (PASS/AF) ,  AFZ-300,  202-267-7976 

o  Air  Traffic  (NATCA) ,  ATZ-2,  202-267-3022 

o  Air  Traffic  (NAATS) ,  ATZ-2,  202-267-3022 

o  Flight  Standards  (PASS/FS),  AFS-6,  202-267-3928 

o  Office  of  Labor  and  Employee  Relations,  ALR-100, 
202-267-3409 

Reference  Documents 

The  following  documents  are  the  basis  for  the  guidelines 
presented: 

o  Federal  Service  Labor-Management  Relations  Statute,  5 
U.S.C.  Chapter  71 

o  1993  NATCA/FAA  negotiated  agreement,  Articles  7  and  48 

o  1992  PASS (AF) /FAA  negotiated  agreement,  Articles  69  and 
70 

o  1993  NAATS/FAA  negotiated  agreement.  Article  9 

o  1993  PASS (FS) /FAA  negotiated  agreement,  Articles  68  and 
69 

o  FAlA  Order  3710. 7C,  Labor  Management  Relations  Program 

o  FAA  Order  1100. 2C,  Organization  -  FAA  Headquarters 

Point  of  Contact  for  Chapter  20  is  Susanna  Leon-Guerrero, 

ALR-100,  202-267-3409. 
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QUESTIONS  CONCERNING  IMPACT  OF  NEW  TECHNOLOGY 
TO  ASSIST  IN  DETERMINING  WHETHER  OR  NOT 
THERE  IS  IMPACT  ON  BARGAINING  UNIT  EMPLOYEES 


NOTE:  Any  affirmative  responses  to  this  checklist  must  be  fully 

explained  in  the  executive  summary,  Figure  20.2, 

Does  implementation  of  the  new  system  affect  the  following: 

a.  Grades  of  employees? 

b.  Number  of  employees? 

c.  Change  in  method  of  performing  work? 

1.  Require  or  eliminate  logs  or  other  records? 

2.  Require  use  of  new  tools/procedures/techniques/equipment? 

3.  Require  use  of  new  materials,  solvents,  lasers,  etc.? 

4 .  Work  more  arduous  or  demanding? 

5.  Work  to  be  done  in  teams,  rather  than  individually? 

6.  Require  change  in  computer/human  interface? 

d.  Require  additional  training  or  qualifications,  i.e., 

Academy,  OJT,  directed  study,  etc.? 

1.  Acquire  new  skills? 

2.  Require  new  methods  of  operation? 

e.  Certification  of  employees?  Air  Traffic  _ 

Airway  Facilities  _ 

f.  Organizational  reassignment  to  another  unit,  facility, 
group,  team? 

g.  Affect  the  work  location  of  employees?  City,  remote 
location,  etc. 

h.  Affect  travel  issues? 

1.  Extend  or  decrease  commuting  time  of  employee? 

2.  Require  change  in  travel  to  perform  work? 

3.  Change  travel  method  of  performing  work,  i.e..  Government 
car  vs.  POV? 


FIGURE  20.1 
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QUESTIONS  CONCERNING  IMPACT  OF  NEW  TECHNOLOGY 
TO  ASSIST  IN  DETERMINING  WHETHER  OR  NOT 
THERE  IS  IMPACT  ON  BARGAINING  UNIT  EMPLOYEES 

(CONTINUED) 


i.  Affect  employee'"  s  evaluation  of  performance? 

1.  Elements  and  Standards  change? 

2 .  Rate  changed? 

j.  Affect  overtime  or  other  pay  issues? 

1.  Increase/decrease  in  overtime? 

2.  Increase/decrease  in  night  differential? 

3.  Require  call-back? 

4.  Environmental  pay  affected? 

k.  Require  changed  medical  requirements? 

l.  Require  change  in  working  hours? 

1.  Four  10-hour  days? 

2.  Shift  work? 

3.  Short  turn-arounds? 

4.  Change  in  break  times  or  duration? 

5.  Watch  schedule  changes? 

m.  Change  in  physical  working  environment? 

1.  Different  building? 

2.  Ventilation,  window,  dust,  adequate  CBI  training 
facility? 

3.  Adequate  parking? 

4.  Handicapped  access? 

5.  Modification/construction  in  employee  work  area? 

6.  Access  to  medical  facilities? 

7.  Access  to  child  care  facilities? 

8.  Exposure  to  hazardous  materials? 

n.  Require  change  in  security  clearance? 

o.  Any  other  aspect  of  system  deployment  which  impacts  on 
bargaining  unit  employees. 


FIGURE  20.1 
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INFORMATION  NECESSARY  TO  NOTIFY 
NATIONAL  UNIONS  OF  NAS  DEPLOYMENT 


The  following  information  is  to  be  used  as  a  guide  by  the  PM  in 
developing  an  executive  summary.  These  issues  should  be 
addressed  and  combined  into  executive  summary  format  prior  to 
submittal  to  ALR-100. 

Name  of  project: 

Description  of  project:  (Including  project  functions) 

Impact  on  air  traffic  tower/center  controllers: 

(If  unsure  as  to  what  constitutes  impact,  use  the  attached 
checklist  to  identify  sources  of  impact  and  explain  how  this 
system  will  impact  bargaining  unit  employees) 

Impact  on  air  traffic  assistants: 

Impact  on  airway  facilities  personnel: 

Impact  on  flight  service  station  personnel: 

Impact  on  flight  standards  personnel: 

Date  of  delivery  to  the  field: 

Date  of  deployment: 

Deployment  sites: 

Date,  duration  and  location  of  testing,  if  any: 

Training  necessary: 

o  for  air  traffic  personnel 
o  for  airway  facilities  personnel 
o  for  flight  standards  personnel 

Maintenance  concept: 

Human  factors:  (have  human  factors  been  addressed,  and  if  so, 

to  what  extent) 

Any  other  information  that  may  be  appropriate: 


FIGURE  20.2 


Chapter  21 


This  chapter  describes  the  following  program  reviews:  the 
Program  Director  Status  Review  (PDSR) ,  the  Detailed  Financial 
Review,  and  the  Major  Acquisition  Review.  Each  review  will  be 
presented  separately  within  the  chapter. 

Process  Description  of  the  PDSR 

The  purpose  of  the  PDSR  meeting  is  to  provide  a  forum  for  PMs  to 
present  overall  program  status  to  the  Program  Director,  focusing 
on  the  significant  issues  and  items  which  may  impact  program 
activities  and  schedule.  The  meeting  is  conducted  at  least 
quarterly.  Those  who  are  involved  in  program  activities  and  can 
contribute  to  the  program  briefings  are  invited  to  attend; 
generally,  this  will  include  the  following  persons: 

o  Program  Director  and  counterparts  from  System 

Engineering  and  Technical  Assistance  (SETA)  and  the 
System  Engineering  and  Integration  (SEI)  Contractor 

o  Division  Manager 

o  Associate  Program  Manager  -  Engineering 

o  Program  Manager 

o  Business  Manager 

o  SETA/SEI  planners 

o  Matrix  management  team  to  include  representatives  from 

ATR,  ACN,  AAF,  ANS,  ASM,  AOS,  APM,  ASU,  AGC,  ASE,  AND, 
ACQ,  SEI,  and  program  staff 

Contents  of  the  package  to  be  briefed  at  the  review  include  the 
following : 

o  Project  Performance  Sheet  which  addresses 

accomplishments,  delinquencies,  near-term  activities, 
concerns/issues,  and  action  plans 

o  Summary  Milestone  Schedule  which  includes  the  status  of 
all  applicable  Level  I  milestones 
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o  Status  of  action  items  assigned  in  previous  PDSR 
meetings 

PMs  will  conduct  a  meeting  with  the  appropriate  personnel  to 
prepare  the  package  to  be  presented  at  the  PDSR  meetings.  Figure 
21.1  presents  the  specific  guidelines  for  developing  the  Project 
Performance  Sheet.  Once  this  preparation  meeting  is  completed, 
the  SEI  planner  is  responsible  for  providing  the  following  to  the 
PM  for  signature: 

o  Action  items  updated  to  reflect  current  status 

o  Final  Project  Performance  Sheets 

o  Summary  Milestone  Schedules 

Once  these  items  are  approved  by  the  PM,  the  package  is 
reproduced  and  distributed  to  those  who  attend  the  PDSR  meeting. 
When  the  PDSR  meeting  is  completed,  action  items  assigned  during 
the  meetings  are  incorporated  into  the  package  by  the  SEI  planner 
prior  to  final  distribution.  Final  distribution  is  determined  by 
the  Program  Director.  The  SEI  distributes  the  final  package. 

Lessons  Learned 

The  PDSR  provides  a  disciplined  approach  to  monitoring  progress 
towards  CIP  objectives  and  also  provides  a  forum  to  discuss 
cross-organizational  issues  and  action  plans.  It  is  critical 
that  PMs  engage  themselves  routinely  in  managing  the  programs, 
and  elevate  issues  as  appropriate  to  the  Program  Director  when 
they  occur. 

Responsibilities 

The  PM  is  responsible  for  preparing,  coordinating,  and  approving 
the  package  to  be  briefed  at  the  PDSR  meeting.  The  SEI  supports 
the  effort  to  consolidate  and  distribute  the  package. 

Contacts 

The  following  branch  and  group  may  be  contacted  for  additional 
information  on  the  areas  indicated: 

o  General  Information,  AND-10,  202-267-9026 

o  Milestone  Schedule  Data,  SEI,  202-646-5729 
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Process  Description  for  the  Detailed  Financial  Review 

The  Detailed  Financial  Review  is  a  meeting  conducted  to  provide 
an  informal  forum  for  the  PM  to  present  the  financial  status  of 
the  program  to  the  Program  Director  in  a  consistent,  disciplined 
fashion.  The  meeting  is  chaired  by  the  Program  Director  and 
focuses  on  significant  issues  and  concerns  at  his  level. 

Attendance  at  this  meeting  should  include  the  Program  Director, 
the  PM,  the  Deputy  PM,  the  Program' s  Business  Manager,  the  APME, 
AND-10,  APM-100,  and  SEI  counterparts. 

Elements  of  the  Detailed  Financial  Review  package  include  the 
following : 

o  Director-level  obligation  trends 

o  Program  manager-level  obligation  trends 

o  Project  funding  summary 

o  Total  project  requirements 

o  Project  detailed  obligation  plans 

o  Regional  obligation  summaries 

All  packages  are  approved  and  signed  by  the  PM  prior  to  release 
to  the  SEI  for  further  processing.  Only  one  distribution  of 
approved  packages  is  made.  This  will  be  done  prior  to  the  start 
of  the  meeting  and  will  be  limited  to  the  attendees. 

Lessons  Learned 

A  key  benefit  of  the  Detailed  Financial  Review  process  is  the 
discipline  it  instills  in  the  financial  management  process. 
Detailed  financial  planning  to  identify  when  requirements  need  to 
be  funded  is  an  absolute  necessity  in  this  process.  PM  and 
Business  Managers  must  continuously  monitor  obligations  and 
adjust  their  plans  on  a  real-time  basis.  Accuracy  of  Financial 
Management  System  data  is  paramount . 

Responsibilities 

The  Business  Manager  will  work  with  the  PM  and  SEI  Financial 
Analyst  to  update  advance  procurement,  obligation,  and  funding 
plans.  The  SEI  prepares  a  draft  package  based  on  Program 
Manager/Program  Business  Manager  direction  and  on  data  from  the 
Financial  Management  System.  SEI  will  hold  a  preliminary  meeting 
with  the  PM  and  the  Business  Manager  to  review  the  package.  The 
PM  signs  and  approves  the  package  for  final  presentation  to  the 
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Program  Director.  He  may  delegate  signature  authority  to  his 
deputy  or  Business  Manager. 

Review  and  Approval 

Detailed  Financial  Reviews  are  conducted  by  the  PM  and  the 
Business  Manager;  however,  final  approval  is  given  by  the  PM. 
This  is  sometimes  delegated  to  his  deputy. 

Contacts 

The  following  groups  can  be  contacted  for  additional  information 
in  the  areas  indicated; 

o  General  Information,  AND-10  (202-267-9026),  APM-140 
(202-287-8673) 

o  Financial  Data,  SEI  (202-646-5729) 

Reference  Documents 

The  NAS  Development  Standard  Operating  Procedure  (SOP)  for 
Detailed  Financial  Reviews,  February  1993,  provides  procedural 
guidance  for  this  review.  In  addition,  required  data  and 
information  used  in  the  process  are  also  included  in  the 
following : 

o  Annual  Procurement  Plan 
o  Advance  Acquisition  Plans 
o  Financial  Management  System 

o  FAA  Capital  Investment  Planning  Process  for  FY  1996, 
September  1993 


21-4 


Process  Description  for  Major  Acquisition  Reviews 

Major  Acquisition  Reviews  <MARs)  are  conducted  periodically  in 
accordance  with  TAM  Chapter  34,  Appendix  A  and  Order  1810. IF. 
These  reviews  are  attended  by  senior  managers  from  the  FAA  and 
the  OST.  The  intent  is  to  provide  decision  authorities  with 
sufficient  information  on  the  status  of  major  acquisition 
programs  so  they  can  make  informed  decisions  on  whether  the 
program  should  proceed  as  planned  or  be  modified.  Program  review 
schedules  are  published  by  the  Office  of  Acquisition  Policy  and 
Oversight  (ACQ-1) .  ACQ-1  also  establishes  and  distributes  the 
presentation  format  and  content  to  be  used  at  MARs .  There  is  one 
format  for  Research  and  Development  programs  that  applies  up  to 
and  including  KDP  III,  and  a  second  format  for  programs  in  full- 
scale  development,  production,  or  deployment. 

The  following  areas  are  addressed  at  MARs  for  R&D  programs  (pre 
KDP  III) : 

o  Composition  and  status  of  the  program  management  team 

o  Description  of  mission  need  the  program  is  intended  to 
fulfill 

o  Planned  interfaces  with  other  NAS  systems 

o  Potential  alternative  solutions  being,  or  to  be, 
investigated  for  meeting  mission  need 

o  Overall  program  acquisition  strategy  for  fielding  a 
capability  that  will  satisfy  mission  need 

o  Acquisition  activity  now  ongoing  within  context  of  the 
overall  acquisition  strategy 

o  Overall  program  schedule  and  near-term  activities 
planned  for  next  year 

o  Overall  program  R&D  and  F&E  funding  requirements  and 
shortfalls 

o  Status  of  key  planning  documents 
0  Achievements  since  the  last  MAR 

o  Unresolved  problems,  concerns,  and  issues  and  a  plan  of 
action  for  each 
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The  following  areas  are  addressed  at  MARs  for  F&E  programs  (post 
KDP  III)  : 

o  Composition  and  status  of  the  program  management  team 

o  Program  summary  describing  the  mission  need,  major 

capabilities  to  be  provided,  and  baseline  and  current 
cost  estimates 

o  Achievements,  changes,  and  action  items  since  the  last 
review 

o  Major  acquisition  approval  conditions 

o  Total  program  schedule  and  planned  near-term  activities 
over  the  next  12  months 

o  Status  of  major  planning  documents  and  the  NAILS  support 
strategy 

o  Hardware  and  software  performance  matrices 

o  Status  of  site  preparation  and  interfaces  with  other  NAS 
systems 

o  Funding  requirements,  distribution,  and  changes 

o  Status  of  the  program  obligation  plan 

o  Cost  and  schedule  status  of  the  prime  contract (s) 

o  Major  technical,  cost,  and  schedule  concerns  that  remain 
unresolved 

o  Program  risk  assessment  related  to  performance,  cost, 
and  schedule 

o  Issues  or  approval  actions  needing  top-level  FAA 
management  attention 

The  MAR  provides  a  forum  for  the  PM  to  justify  requests  for 
additional  funding,  air  concerns,  and  advise  the  review  authority 
of  issues  requiring  action.  ACQ-1  independently  assesses  each 
program  for  the  Administrator  and  identifies  factors  that  could 
lead  to  schedule  slips,  cost  growth,  or  other  technical  or 
support  problems.  ACQ-1  also  tracks  the  resolution  of  action 
items  that  occur  at  each  review. 
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Lessons  Learned 


Full  and  open  discussion  of  program  concerns  and  issues  at  MARs 
is  an  opportunity  for  obtaining  management  support  and  activity 
towards  their  resolution.  It  enables  top-level  managers  to  focus 
attention  and  resources  on  problems  before  they  get  out  of  hand, 
and  it  also  protects  PMs  from  having  to  solve  problems  beyond 
their  means  and  authority. 

Discussing  every  data  entry  on  each  MAR  briefing  chart  can  be 
tedious,  boring,  and  counterproductive.  The  MAR  briefing  format 
is  intended  to  serve  both  as  a  permanent  record  of  program  status 
and  as  a  vehicle  for  addressing  important  issues  and  concerns  to 
top  management.  When  preparing  the  MAR  briefing  charts,  PMs 
should  provide  all  the  information  asked  for  in  the  briefing 
instructions.  But  when  presenting  the  material  at  the  MAR 
review,  PMs  should  focus  on  important  topics  of  concern  and  leave 
the  review  of  program  details  to  members  of  the  audience. 

Responsibilities 

The  PM  is  responsible  for  preparing  and  presenting  program  status 
at  each  MAR  in  compliance  with  the  MAR  briefing  format.  ACQ-1  is 
responsible  for  developing  MAR  review  schedules,  maintaining  and 
disseminating  the  MAR  format,  independently  assessing  each 
program,  and  providing  findings  to  the  PM  and  upper  FAA 
management,  tracking  the  completion  of  action  items. 

Contacts 

The  following  organizations  may  be  contacted  for  additional 
information : 

o  MAR  briefing  format,  ACQ-1,  202-267-7601 

o  MAR  briefing  schedule,  ACQ-1,  202-267-8934 

Point  of  Contact  for  Chapter  21  is  Chuck  Whelan,  SEIC, 
202-646-5729 . 
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GUIDELINES  FOR  DEVELOPING  THE  PDSR 
PROJECT  PERFORMANCE  SHEET 


General 

Information  and  schedules  presented  to  the  Program  Director 
should  be  coordinated  with  all  affected  organizations;  the  PM  is 
responsible  for  notifying  the  Program  Director  of  areas  of 
disagreement . 

Accomplishments 

PMs  should  focus  on  significant  accomplishments.  Suggestions 
would  include  completed  Levels  I  or  II  milestones,  items  from  the 
previous  PDSR  near-term  activities,  or  any  other  significant 
accomplishments.  The  timeframe  to  be  considered  will  be  from  the 
last  PDSR  meeting  status  date  to  the  current  PDSR  status  date, 
usually  two  months. 

Delinquencies 

Generally,  any  item  which  was  listed  as  a  near-term  activity  in 
the  previous  PDSR  package  and  was  not  accomplished  should  be 
listed  as  a  delinquent  item.  Also,  significant  contractor 
activities  which  have  not  been  completed  per  the  contract 
schedule  should  be  listed. 

Near-Term  Activities 

The  PM  should  focus  on  significant  activities.  Suggestions  would 
include  Level  I  or  II  milestones  or  significant  contractor 
activity.  The  timeframe  to  be  considered  will  be  the  next  60 
days  beyond  the  current  PDSR  status  date. 

Concerns  and  Issues 

PMs  should  address  not  only  those  concerns  and  issues  which  are 
currently  impacting  the  program,  but  also  those  which  may 
significantly  impact  the  program  in  the  future.  Concerns  would 
include  items  which  should  be  highlighted  to  the  Program  Director 
but  are  being  worked  by  the  PM;  issues  would  require  Program 
Director  assistance  for  resolution.  Any  significant  concerns  and 
issues  pertaining  to  the  following  major  areas  should  be  listed: 


FIGURE  21.1 
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GUIDELINES  FOR  DEVELOPING  THE  PDSR 
PROJECT  PERFORMANCE  SHEET  (CONT.) 


o  Procurement  and  contract  activities  (PRR,  PR,  RFP, 
contract,  contract  modifications) 

o  Design,  development  evaluation  and  progress  (including 
design  reviews) 

o  Technical  evaluation  and  progress 

o  National  Airspace  Integrated  Logistics  Support  (NAILS) 

o  Configuration  management  (Functional  Configuration  Audit 
and  Physical  Configuration  Audit) 

o  Testing,  evaluation  and  progress  (contractor,  T&E, 
regional) 

o  Deployment  Readiness  Review  (refer  to  DRR  checklist) 

o  Implementation  (delivery,  installation/acceptance,  ORD) 

o  Interdependencies  (your  project  is  dependent  on  another 
project  or  another  project  is  dependent  on  yours) 

o  Overall  schedule  and  cost  concerns 

o  Overall  contractor  performance 

o  Audit  (GAO,  IG,  AXQ) 

o  Significant  field  contact  and  activities  (e.g.,  field 

team  writing  a  Project  Implementation  Plan  or  developing 
test  plans) 

Descriptions  of  concerns  and  issues  should  be  brief  and  concise, 
yet  should  provide  the  necessary  information.  For  example, 
"CONTRACTOR  WILL  NOT  MEET  CONTRACT  SCHEDULE"  is  brief  and  does 
not  provide  specifics.  "CONTRACTOR  FACTORY  TESTING  WILL  BE 
DELAYED  2  MONTHS  BEYOND  CONTRACT  SCHEDULE  DUE  TO  SUBCONTRACTOR' S 
INABILITY  TO  SUCCESSFULLY  TEST  AND  DELIVER  INTERFACE  CARDS"  is 
brief  but  provides  a  much  clearer  description  of  the  issue. 
Descriptions  should  generally  describe  who,  what,  when,  and  why. 


FIGURE  21.1 
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GUIDELINES  FOR  DEVELOPING  THE  PDSR 
PROJECT  PERFORMANCE  SHEET  (CONT.) 


Each  concern  or  issue  will  be  immediately  followed  by  a 
description  of  the  action  plan  rather  than  grouping  all  of  the 
concerns  and  issues  followed  by  a  group  of  action  plans.  Note 
that  the  standard  format  will  not  require  a  separate  NAILS 
section;  any  concerns  or  issues  in  this  area  should  be  listed 
under  the  "CONCERNS/ISSUES"  section. 

Action  Plan 

Each  concern  or  issue  must  have  a  corresponding  action  plan. 
Action  plan  descriptions  should  be  brief  and  succinct  while 
providing  significant  information.  The  writeup  should  provide 
summary  of  the  following:  what  the  action  plan  is;  who  has 
primary  responsibility  for  implementing  the  plan;  and  the 
completion  date. 
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Chapter  22 


This  chapter  is  based  on  information  in  the  "Guide  to  the 
Preparation  of  Agency  Procurement  Requests",  February  1994.  For 
more  complete  information,  consult  with  AIT-200  or  review  the 
Guide  itself. 

Introduction 

The  Administrator  of  the  General  Services  Administration  (GSA) 
has  the  exclusive  authority  within  the  Federal  Government  to 
procure  and  manage  Federal  Information  Processing  (FIP) 
resources,  including  telecommunications,  software,  and  services. 
When  an  agency  needs  to  conduct  an  acquisition  for  FIP  resources, 
they  must  have  sufficient  procurement  authority  before  issuing  a 
solicitation.  For  smaller  acquisitions,  GSA  has  granted 
automatic  authority,  called  a  regulatory  blanket  delegation,  to 
federal  agencies,  such  as  the  Office  of  the  Secretary  for 
Transportation  (OST) .  OST  has,  in  turn,  redelegated  limited 
procurement  authority  to  the  Federal  Aviation  Administration 
(FAA) .  Figure  22.1  summarizes  the  procurement  authority 
thresholds  and  identifies  who  has  what  authority.  In  all  cases 
where  a  proposed  procurement  will  exceed  the  FAA  delegation,  the 
program  office  must  prepare  an  Agency  Procurement  Request  (APR) 
to  obtain  a  specific  Delegation  of  Procurement  Authority  (DPA) 
before  proceeding  with  the  procurement . 

Frequent  reference  is  made  to  the  Federal  Information  Resources 
Management  Regulation  (FIRMR) ,  which  is  promulgated  by  GSA  as 
part  of  the  Code  of  Federal  Regulations.  The  FIRMR  codifies 
government  policy  and  procedures  for  all  aspects  of  managing 
Information  Resources  Management  (IRM) .  Reference  copies  of  the 
FIRMR  should  be  available  in  the  program  office,  the  Office  of 
Information  Technology  (AIT) ,  and  the  Office  of  Contracting  and 
Quality  Assurance  (ASU)  representatives.  (Copies  can  be  ordered 
from  the  Government  Printing  Office) . 

The  problem  areas  associated  with  APRS  are  usually  ones  of 
omission  and  clarity,  where  required  documentation  is  missing  or 
is  not  clearly  presented.  The  APR  should  be  specific,  clear,  and 
not  unnecessarily  technical,  and  should  contain  sufficient 
information  to  explain  fully  to  the  reader  what  the  writer 
intends . 
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For  reasons  of  economy  and  efficiency,  GSA  directs  each  agency  to 
select  a  Designated  Senior  Official  (DSO)  to  be  responsible  for 
the  acquisition  and  management  of  FIP  resources.  The  DSO  for  the 
Department  of  Transportation  is  the  Assistant  Secretary  of 
Administration  (M-1) .  The  DSO  for  the  FAA  is  the  Assistant 
Administrator  for  Information  Technology  (AIT-1) .  Requests  for 
DPAs  are  made  and  DPAs  are  granted  through  the  DSO  channels. 

Under  the  direction  of  the  DSO,  FAA  is  allowed  to  contract  for 
FIP  resources: 

o  In  accordance  with  the  FAA  blanket  DPA  (OST  Order  1350.2 
and  FAA  Order  1370. 52C) 

o  When  a  specific  delegation  of  procurement  authority  has 
been  provided  by  OST  in  accordance  with  the  agency/OST 
regulatory  delegation  provisions  (201-20.305-1) 

o  When  a  specific  agency  delegation  has  been  provided  by  GSA 
(201-20.305-2) 

o  When  a  specific  acquisition  delegation  has  been  provided 
by  GSA  (210-20.305-3) 

In  the  FIRMR,  GSA  has  divided  FIP  resources  into  "types",  and 
assigned  a  dollar  threshold  for  each,  above  which  agencies  must 
obtain  GSA  approval  (DPA)  before  beginning  the  contracting 
process . 

The  different  FIP  types  are: 
o  FIP  Equipment 
o  FIP  Software 
o  FIP  Support  Services 
o  Other  FIP  Services 

Purpose:  The  Agency  Procurement  Request  (APR)  is  the  vehicle  for 

obtaining  procurement  authority  so  that  a  government  agency  can 
obligate  funds  to  acquire  FIP  resources.  It  is  part  of  the  pre¬ 
procurement  approval  process,  designed  to  ensure  compliance  with 
agency,  department,  and  GSA  requirements  (such  as  those  in  the 
FIRMR) .  The  APR  is  also  designed  to  ensure  that  exceptions  to 
full  and  open  competition  are  well  documented. 

Planning  Requirements:  Agencies  are  required  to  report  on 
planned  and  actual  expenditures  for  information  technology  in 
accordance  with  0MB  Circular  A-11.  Agency  Information  Resource 
Management  (IRM)  officials  are  responsible  for  monitoring 
requirements  and  developing  plans  to  meet  future  needs  that  are 
the  most  advantageous  to  the  Government  (i.e.,  lowest  overall 
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cost) .  FAA  uses  IRM  reports  and  the  Capital  Investment  Plan 
(CIP)  to  support  agency  FIP  program  requirements.  Agency 
procurement  request  packages  should  reference  the  budget  line 
item  page  number  and/or  CIP  project  that  the  proposed  acquisition 
supports . 

Circumstances  Requiring  an  APR 

An  APR  is  needed  in  all  cases  where  a  proposed  procurement  will 
exceed  the  authority  level  delegated  by  OST.  If  the  planned 
acquisition  is  not  covered  by  a  regulatory  or  specific  agency 
DPA,  the  APR  must  be  submitted  to  GSA.  If  the  acquisition  is 
within  the  departmental  regulatory  delegation  threshold,  then  an 
APR  shall  be  submitted  to  OST. 

Blanket  DPAs  and  Dollar  Thresholds:  OST  has  delegated 
limited  procurement  authority  to  the  FAA,  which  has  been 
redelegated,  in  full,  to  all  FAA  organizations  (to  the 
Associate  Administrator  or  equivalent  level) .  FIP  resources 
of  varying  types  may  be  combined  and  procured  under  a  single 
procurement  action.  However,  GSA  approval  is  required  when 
the  price  or  charges  for  any  one  of  these  types  exceeds  the 
applicable  dollar  threshold  (201-20.305-1).  Requirements 
may  not  be  separated  in  order  to  circumvent  the  thresholds. 
The  thresholds  referenced  represent  the  purchase  price  of 
the  information  resource.  Purchase  price  is  the  contract 
value  over  the  entire  contract  life,  including  all  options. 
Currently,  the  FAA  has  a  blanket  agency  DPA  for  National 
Airspace  Systems  (NAS)  operational  telecommunications. 

Competitive  Procurement  Thresholds:  The  basic  procurement 
objective  in  satisfying  FIP  and  telecommunications 
requirements  is  to  obtain  full  and  open  competition  through 
the  use  of  competitive  procedures.  In  recognition  of 
attaining  this  objective,  GSA  has  afforded  federal  agencies 
the  most  generous  procurement  authority  when  contracting 
under  competitive  procedures.  This  procurement  authority 
has  been  extended  to  Small  Business  Administration  (SBA) 

8(a)  set-aside  contracting.  It  is  the  responsibility  of 
each  program  office  to  construct  their  requirements  and 
projects  in  a  manner  that  will  maximize  competitive 
solutions . 

Non-Competitive  Procurement  Thresholds:  Very  restrictive 
procurement  authority  has  been  afforded  by  GSA  for 
contracting  with  requirements  available  from  only  one  source 
and  with  make  and  model  specifications,  regardless  of  the 
number  of  competing  contractors.  This  includes  sole  source 
8 (a)  and  specific  make  and  model  8 (a) .  Whenever  possible, 
competitive  contracting  should  be  utilized.  When  an  agency 
finds  that  competition  cannot  be  attained  in  satisfying  a 
FIP  requirement,  the  procurement  action  must  be  justified 
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and  approved.  The  FIRMR  does  not  impose  an  additional  layer 
of  requirements,  but  instead  relies  on  the  Federal 
Acquisition  Regulation  (FAR)  provisions  and  internal  agency 
procedures.  Be  careful  that  all  of  the  required  analysis 
and  studies  that  support  other  than  competitive  contracting 
are  performed  and  documented.  When  there  is  only  one 
responsible  source  or  there  is  a  make  and  model 
specification,  a  copy  of  the  approved  justification  of  other 
than  full  and  open  competition  must  be  attached  to  the  APR. 

Preparation  and  Approval  {APR  Process) 

Before  Preparing  an  APR:  For  procurements  requiring 
Acquisition  Review  Committee  (ARC)  approval,  the  APR  should 
be  submitted  only  after  the  ARC  has  given  final  approval  to 
the  Mission  Need  Statement.  The  Mission  Need  Statement 
contains  information  to  comply  with  the  FIRMR' s  Requirements 
Analysis  and  Analysis  of  Alternatives  documentation 
requirements.  The  Mission  Need  Statement  should  then  be 
attached  to  the  APR.  For  smaller  procurements  not  reviewed 
by  the  ARC,  the  APR  should  be  prepared  after  the  appropriate 
management  level  has  approved  the  acquisition.  Copies  of 
the  Requirements  Analysis  and  the  Analysis  of  Alternatives 
should  be  attached  to  the  APR.  For  those  procurements  being 
acquired  where  only  one  responsible  source  exists  or  a 
specific  make  and  model  is  required,  the  appropriate 
justification  should  be  approved  before  submitting  the  APR. 
The  approved  justification  should  be  attached  to  the  APR 
when  it  is  submitted  to  AIT.  An  APR  must  be  approved  by 
GSA/OST  and  a  DPA  granted  before  any  solicitation  can  be 
issued.  The  quality  of  the  material  prepared  heavily 
impacts  the  length  of  the  APR/DPA  process.  A  poorly 
prepared  APR  and  supporting  documentation  can  greatly 
lengthen  the  processing  time.  AIT-200  will  gladly  critique 
your  draft  documentation  to  be  sure  you  are  presenting  an 
understandable  request . 

Description  of  Process:  For  a  graphical  depiction  of  the 
APR/DPA  process,  see  Figure  22.2.  The  APR  package  is  sent 
to  AIT-1 .  AIT-200  (supporting  AIT-1)  reviews  the  package 

for  FIRMR  compliance  and  coordinates  with  the  Office  of 
Contracting  and  Quality  Assurance  (ASU) .  When  approved  by 
AIT-1,  the  formal  FAA  request  is  transmitted  to  the  Office 
of  Information  Resource  Management,  M-30  in  OST,  acting  on 
behalf  of  the  OST  DSO.  During  the  OST  review,  a 
presentation  on  the  proposed  procurement  may  be  requested. 

If  this  is  necessary,  M-30  will  contact  AIT-200  and  the  FAA 
project  manager  to  set  up  the  formal  presentation.  If  the 
planned  procurement  requires  OST  approval  only,  M-30  will 
grant  the  delegation  to  the  FAA  in  a  memo  to  AIT-1 .  AlT-1 
will  redelegate  the  authority  to  the  contracting  officer 
through  the  program  office.  A  copy  of  the  DPA  will  be  sent 
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to  ASU  by  AIT.  If  the  procurement  requires  GSA  approval,  M- 
30  will  transmit  the  request  to  GSA.  The  formal  GSA  review 
and  approval  cycle  begins  when  the  APR  is  received  at  GSA. 

A  few  days  after  receipt  of  the  APR,  the  Authorizations 
Branch  of  GSA  may  request  a  briefing  by  M-30  on  the  package. 
If  this  happens,  the  same  briefing  process  described  above 
will  occur.  GSA  will  usually  approve  or  deny  the  request  in 
as  little  as  a  week  for  smaller  competitive  procurements  but 
may  take  up  to  20  working  days  for  larger  comprehensive 
systems  acquisitions.  GSA  will  notify  M-30,  who  will  then 
notify  AIT-1  by  mail.  You  will  be  kept  informed  of  the 
progress  of  the  above  process  by  AIT-200.  The  office 
originating  the  APR  will  receive  notification  from  M-30 
through  AIT  that  the  delegation  has  been  granted  and  that 
the  procurement  can  proceed.  ASU  also  receives  a  copy  of 
the  memo.  The  memo  granting  the  delegation  and  the  APR  upon 
which  it  is  based  should  be  held  in  the  procurement 
documentation  file  for  reference,  particularly  in  the  event 
that  an  amendment  to  the  delegation  is  required  to  complete 
the  project  procurement  during  the  contract  life.  The  APR 
package  consists  of  the  APR  and  supporting  documentation. 

The  size  of  the  APR  submission  package  will  vary  with  the 
size  and  complexity  of  the  procurement.  Supporting 
documentation  includes  the  Requirements  Analysis,  the 
Analysis  of  Alternatives  (or  Mission  Need  Statement) ,  and, 
where  applicable,  the  conversion  study,  the  findings  to 
support  compatibility-limited  requirements,  the  sole  source 
justification,  etc.  This  material  should  be  developed  as 
part  of  the  project  planning  and  should  not  be  viewed  as  an 
additional  requirement  of  the  APR. 

APR  Format:  The  APR  format  used  to  obtain  a  DPA  from  GSA  is 
also  used  to  obtain  a  DPA  from  OST,  using  their  blanket 
authority.  An  APR  quick  reference  can  be  found  in  the  Guide 
to  the  Preparation  of  Agency  Procurement  Requests.  The  APR 
is  nothing  more  than  a  formatted  staff  paper. 

APR  Supporting  Documentation:  The  APR  package  contains  the 
essential  information  needed  by  OST  or  GSA  to  grant  a  DPA. 
The  package  also  contains  certifying  statements  that  the 
procurement  satisfies  all  FIRMR  and  OST  requirements.  The 
supporting  documentation  for  the  procurement,  when  combined 
with  the  APR,  constitutes  the  APR  package  referenced 
earlier.  Please  note  that  FIRMR  documentation  is  required 
even  for  those  acquisitions  conducted  under  the  FAA  blanket 
authority  and  is  not  created  solely  for  the  APR.  Because 
these  are  relatively  small  procurements,  the  size  of  each 
document  will  most  likely  be  fairly  small.  The  FIRMR 
requires  agencies  to  establish  and  document  requirements  for 
FIP  resources  by  conducting  a  Requirements  Analysis 
commensurate  with  the  size  and  complexity  of  the  need.  This 
Requirements  Analysis  is  to  be  used  as  the  basis  for 
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analyzing  alternatives  to  identify  the  most  advantageous 
alternative  to  the  Government,  cost  and  other  factors 
considered.  The  most  favorable  alternative  becomes  the 
project  acquisition  you  are  about  to  undertake.  The 
information  in  the  Requirements  Analysis  and  Analysis  of 
Alternatives  is  developed  as  a  part  of  the  normal  FAA 
management  decision  making  process.  Management  approval, 
budget  commitments,  etc.,  are  based  on  the  requirements  and 
an  examination  of  various  alternative  ways  to  fulfill  those 
requirements.  The  APR  documentation  is  a  complete  synopsis 
of  the  studies,  not  a  requirement  to  perform  another 
requirements  or  alternatives  analysis.  A  Mission  Need 
Statement  fulfills  the  need  for  a  Requirements  Analysis 
statement  and  an  Analysis  of  Alternatives  statement.  For 
those  acquisitions  for  which  a  Mission  Need  Statement  has 
been  prepared,  no  additional  requirements  statement  is 
needed . 

Requirements  Analysis  (201-20.1)  (Required  with  every 
APR) :  The  Requirements  Analysis  documents  requirements 

for  FIP  resources.  It  provides  the  basis  on  which  the 
alternatives  for  meeting  the  requirements  can  be 
analyzed.  Agencies  are  required  to  conduct  a 
Requirements  Analysis  that  is  commensurate  with  the  size 
and  complexity  of  the  need.  Requirements  should  be 
expressed  in  the  form  of  deficiencies  in  existing 
capabilities,  new  or  changed  program  requirements,  or 
opportunities  for  increased  economy  and  efficiency.  A 
contract  for  FIP  resources  is  not  a  requirement .  The 
requirement  is  for  a  means  to  an  end.  The  contract  is 
one  of  the  alternative  solutions.  The  FIRMR  requires 
agencies  to  determine  a  system  life  as  part  of  each 
Requirements  Analysis.  The  system  life  is  used  during 
the  Analysis  of  Alternatives  to  ensure  that  feasible 
alternatives  are  compared  fairly  over  an  identical, 
realistic  time  period.  The  statement  of  requirements 
that  results  from  the  Requirements  Analysis  is  the  basis 
for  the  Analysis  of  Alternatives.  This  statement  must 
be  documented  and  be  a  part  of  the  APR  package. 
Requirements  should  be  expressed  in  non-technical  terms 
without  assuming  that  the  reader  knows  what  is  being 
described.  Requirements  should  be  stated  in  terms  of 
functions  to  be  performed  or  the  level  of  performance  of 
functions,  rather  than  how  the  functions  will  be 
accomplished.  If  at  all  possible,  do  not  construct  the 
requirements  statement  in  a  manner  that  would  require 
non-competitive  procurement. 

Analysis  of  Alternatives  (201-20.2)  (Required  with  every 
APR) :  The  previously  completed  Requirements  Analysis  is 

the  basis  for  evaluating  the  alternatives.  An  Analysis 
of  Alternatives  should  be  performed  for  each  identified 
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requirement.  It's  purpose  is  to  compare  and  evaluate 
various  alternatives  for  meeting  the  requirements  and  to 
determine  which  alternative  is  most  advantageous  to  the 
Government.  A  Mission  Need  Statement  fulfills  the  need 
for  an  Analysis  of  Alternatives  statement .  For  those 
acquisitions  for  which  a  Mission  Need  Statement  has  been 
prepared,  no  additional  Analysis  of  Alternatives 
statement  is  needed. 

Findings  To  Support  Compatibility-Limited  Requirements 
(201-20.103-4):  A  compatibility-limited  requirement  is 

a  statement  of  FIP  resource  requirements  that  requires 
the  items  to  be  compatible  with  existing  FIP  resources. 
Agencies  are  required  to  justify  compatibility-limited 
requirements  for  FIP  resources  on  the  basis  of  at  least 
one  of  the  following: 

o  The  agency  has  technical  or  operational  requirements 
for  compatibility  when  adding  resources  to,  or 
replacing  a  portion  of,  an  installed  base  of 
resources,  and  the  agency  determines  that  replacing 
additional  portions  of  the  installed  base  to  avoid 
compatibility-limited  requirements  is  not 
advantageous  to  the  Government,  or 

o  The  agency  determines  that  the  risk  and  impact  of  a 
conversion  failure  on  agency  critical  mission  needs 
would  be  so  great  that  acquiring  non-compatible 
resources  is  not  a  feasible  alternative 

Conversion  Study  (201-20.203-4):  A  conversion  study  is 
used  to  assess  the  costs,  risks,  and  magnitude  of 
converting  installed  FIP  resources  to  replacement  or 
augmentation  resources.  A  conversion  study  must  be  made 
for  all  FIP  procurements  unless  it  is  an  initial 
acquisition,  acquires  peripherals  only,  or  is  a  purchase 
option  on  an  existing  lease. 

Justification  for  Other  Than  Full  and  Open  Competition: 
Justifications  for  other  than  full  and  open  competition 
are  required  by  the  FAR  (see  FAR  Subpart  6.3)  whenever 
contracting  under  other  than  full  and  open  competition. 
Sole  source  FIP  acquisitions  have  no  additional  or 
different  requirements  than  other  forms  of  sole  source 
acquisition . 

Findings  to  Support  Acquisition  of  Specific  Make  and 
Model  (201-39.601):  An  acquisition  that  uses  a  specific 
make  and  model  specification  does  not  provide  for  full 
and  open  competition  and  must  be  justified  and  approved 
in  accordance  with  FAR  6.303  and  6.304. 
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Transmittal  Memos:  The  transmittal  memo  with  the  APR 
package  attached  should  be  sent  from  the  Associate 
Administrator  (or  equivalent)  for  the  Program  Office 
requesting  the  DPA  to  the  Associate  Administrator  for 
Information  Technology  (AIT-l) . 

Contacts 

We  would  appreciate  any  comments  and/or  recommendations  to 
improve  the  Guide  to  the  Preparation  of  Agency  Procurement 
Requests.  Please  send  them  to  Jim  Harris,  202-267-9994  or  Kathy 
Simays  Header,  202-267-8183,  both  of  AIT's  IT  Policy  and  Planning 
Division,  AIT-200. 

Point  of  Contact  for  Chapter  22  is  Kathy  Simays  Header,  AIT-200, 
202-267-8183. 
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LEVELS  OF  APPROVAL  FOR  DELEGATIONS 


22-9 


FIGURE  22.1 


AGENCY  PROCUREMENT  REQUEST/DELEGATION 
OF  PROCUREMENT  AUTHORITY  PROCESS 


FIGURE  22.2 


Chapter  23 


This  chapter  provides  information  on  lessons  learned  that  have 
broad  application  to  the  acquisition  process,  but  are  not  related 
to  one  specific  chapter  in  this  guide.  The  items  presented  here 
are  divided  into  two  groups:  general  acquisition  topics  and 
contract  considerations. 

General  Acquisition  Topics 

o  Plan  program  schedules  and  budgets  realistically. 

Historically,  it  has  taken  7  to  12  years  (and  longer  for 
more  complex  systems)  to  field  new  capability.  Experience 
has  shown  it  is  difficult  or  impossible  to  make  up  lost  time 
through  "work-around"  action  in  the  acquisition  process. 
Everything  takes  longer,  costs  more,  and  requires  more 
coordination  than  appears  necessary  on  the  surface. 

Some  major  reasons  for  lost  time  in  the  acquisition  process  are: 

-  Failure  to  adequately  define  or  revalidate  requirements 
at  each  KDP,  and  maintain  customer  involvement 
throughout  the  process 

-  Failure  to  complete  development  before  authorizing  full 
production  go-ahead 

-  Failure  to  control  changes  to  program  and  contract 
requirements 

Inadequate  attention  to  the  complexities  of  software 
development,  hardware/software  integration  and  testing 

Administrative  delay  in  getting  approval  of  critical 
documents,  and  incomplete  documentation 

o  The  PM  should  form  a  project  team  or  integrated  product 
development  team  composed  of  the  technical,  logistics, 
contractual,  operational,  and  other  specialists  needed  to 
accomplish  program  objectives  as  soon  as  possible  after  the 
program  is  established.  Failure  to  do  so  usually  results  in 
confusion,  schedule  slippage,  and  costly  rework  of ^ 
requirements  and  procurement  documents.  Meeting  milestones 
in  an  acquisition  is  the  result  of  a  joint  team  effort,  not 
an  individual  effort. 
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Users  must  be  involved  in  all  phases  of  a  program  from 
development  of  requirements  to  deployment  in  the  field. 

User  input  during  program  formulation  facilitates  acceptance 
of  the  product.  User  input  should  be  obtained  continuously 
to  revalidate  requirements,  provide  input  on  proposed 
changes,  assess  impact  of  changes  and  address  training, 
transition,  and  NAILS  issues. 

o  In  almost  all  acquisitions,  certain  key  requirements  drive 
system  acquisition  and  life-cycle  costs.  At  the  start  of 
every  development  program,  determine  if  cost-driving 
requirements  can  be  relaxed  and  still  meet  all  essential 
requirements,  or  if  NDI  equipment  can  be  used  to  reduce 
costs,  risk,  or  improve  schedule.  Unless  these  cost-drivers 
are  identified  and  controlled  up  front,  the  project  has 
little  chance  of  being  completed  within  budget. 

o  When  needed,  risk  reduction  tasks  should  be  funded  along 

with  the  basic  acquisition  to  increase  confidence  that  the 
system  will  perform  as  intended  and  at  the  lowest  acceptable 
cost  and  technical  risk. 

o  Up  to  90  percent  of  the  life-cycle  cost  of  a  major  project 
is  in  operations  and  support.  An  objective  in  development 
and  acquisition  should  be  to  minimize  life-cycle  costs.  A 
small  additional  investment  in  R&D  and  acquisition  often 
results  in  substantial  savings  in  operations  and  support 
costs.  Training,  documentation,  spares,  staffing,  and  other 
NAILS  requirements  should  be  identified  at  the  PRR  and 
NAILSMT,  not  at  the  DRR. 

o  PMs  must  consider  how  changes  in  the  state-of-the-art  over  a 
system's  life  cycle  will  affect  support  and  product 
improvement  efforts.  Plan  to  take  advantage  of  improvements 
as  part  of  a  pre-planned  product  improvement  program. 

o  Specifications  and  standards  must  be  tailored  to  the 

requirements  of  each  acquisition.  Functional  specifications 
are  appropriate  for  most  procurements.  Most  specifications 
reference  other  specifications  in  a  way  that  can  have  a 
major  impact  on  product  cost.  Every  referenced 
specification  should  be  reviewed  to  determine  if  it  is 
appropriate  for  use  "as  is"  or  whether  it  should  be  tailored 
to  the  requirements  of  the  procurement.  Requirements  that 
are  not  necessary,  unenforceable,  or  that  there  is  no 
intention  of  enforcing  should  not  be  included. 

o  The  use  of  NDI  that  is  commercially  available  and  capable  of 
fulfilling  essential  FAA  needs  may  minimize  or  eliminate 
costly,  time-consuming  research  and  development.  NDI  offers 
an  opportunity  to  field  state-of-the-art  technology  rapidly, 
particularly  in  the  electronics/communications  fields.  With 
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NDI,  there  is  almost  always  integration  required  with  other 
FAA  systems.  Support  of  NDI  during  its  deployment  as  part 
of  the  NAS  must  be  carefully  evaluated  during  the  market 
analysis  process  to  ensure  FAA  needs  can  be  met.  The  FAA 
can  take  advantage  of  savings  in  cost,  time,  support,  and 
maintenance . 

o  Early  industry  involvement  in  the  acquisition  process  can 
provide  excellent  feedback  to  the  project  manager, 
particularly  on  the  availability  of  NDI.  Ways  to  obtain 
early  industry  involvement  include  releasing  draft 
specifications  for  review,  briefing  industry  on  program 
plans,  issuing  draft  solicitations,  and  meeting  with 
individual  companies . 

o  T&E  is  key  to  a  successful  program.  The  test  and  evaluation 
master  plan  (TEMP)  and  philosophy  should  be  developed 
concurrently  with  the  acquisition  strategy.  Subsystem  and 
component  testing  should  be  used  to  determine  whether 
software,  products,  or  piece  parts  meet  requirements  so  that 
necessary  adjustments  can  be  made  early  in  the  program.  We 
can  avoid  many  problems,  particularly  those  dealing  with 
deficiencies  found  during  OT&E  when  we  do  adequate  testing 
early  on.  When  acquiring  NDI,  use  of  existing  test  data  and 
information  should  be  considered  instead  of  Government 
testing.  In  order  to  make  up  for  schedule  delays,  testing 
should  not  be  reduced  or  eliminated,  because  historically 
this  has  resulted  in  major  operational  problems  and  higher 
program  costs . 

o  Software  and  hardware/software  integration  account  for  a 

disproportionate  share  of  the  problems  encountered  on  many 
NAS  programs.  Historically,  initial  time  and  cost  estimates 
to  develop  and  produce  complex  software  have  been  grossly 
underestimated.  This  causes  schedule  delays,  cost 
increases,  non-delivery  of  specified  functionality,  and 
substantial  increases  in  the  lines  of  code  to  be  developed 
or  modified.  To  minimize  software  problems,  we  must  track 
the  implementation  of  each  specified  requirement  into 
software  code,  as  well  as  maintain  indepth  visibility  into 
the  software  development,  integration  and  documentation 
process.  Because  knowledge  does  not  guarantee  a  quality 
product,  these  steps  will  not  automatically  cause  software 
to  be  delivered  on  schedule  and  within  cost.  But  they  will 
reduce  the  number  of  unexpected  problems  and  improve  the  PMs 
ability  to  retain  the  initiative. 

o  Design  of  the  acquisition  strategy  is  as  important  as  the 

system  design.  Procurement  planning  should  start  early,  and 
acquisition  strategy  approved  by  senior  management  before 
the  plan  is  finalized.  Considerable  confusion  exists  as  to 
when  a  Delegation  of  Procurement  Authority  is  required  from 
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GSA.  This  issue  must  be  resolved  in  the  planning  process  to 
avoid  lengthy  delays.  AIT-340  should  be  contacted  to 
clarify  any  issues  in  this  area. 

o  At  the  beginning  of  the  program/project,  program  offices 

should  coordinate  with  the  Telecommunications  Management  and 
Operations  Division  (ASM-300)  to  ensure  that 
telecommunications  needs  can  be  fulfilled.  In  order  to 
minimize  stand-alone  independent  telecommunications  networks 
and  to  maximize  the  use  of  FAA— owned  networks  versus  leased 
networks,  all  NAS  programs  with  telecommunications 
connectivity  requirements  must  comply  with  Orders  relating 
to  telecommunications  management.  (A  draft  Order, 
Telecommunications  Asset  Management  is  currently  being 
prepared  by  ASM-300  for  review  and  comment) . 

o  Site-specific  installation  issues  are  not  usually  addressed 
early  enough  in  the  program.  Involving  the  potential  users 
early  can  pinpoint  issues  that  can  be  potentially 
troublesome  and  costly  if  left  to  be  addressed  at  the  DRR. 

Contract  Considerations 

Some  major  reasons  for  lost  time  in  the  contracting  process  are: 

-  Budgeting  for  program  success  based  on  "best  case" 
outcomes  for  all  program  activities 

-  Requesting  the  ARC  or  TSARC  to  waive  program 
documentation  requirements  in  order  to  "speed  up" 
program  implementation.  This  seldom,  if  ever,  occurs. 

-  Avoiding  getting  a  DPA  from  GSA.  If  there  are  Federal 
Information  Processing  Resources  involved,  it  needs  a 
DPA  and  a  solicitation  cannot  be  issued,  let  alone  a 
contract,  without  a  DPA. 

-  "Turning  on"  a  contractor  to  making  system  changes 
before  obtaining  a  proposal  or  "not-to-exceed"  cost 

-  Using  an  overly  optimistic  delivery  date  to  motivate 
early  completion 

o  The  contractor  is  required  to  submit  a  fully  priced  proposal 
for  all  changes  issued  by  the  Contracting  Officer  to  an 
existing  contract.  No  changes  should  be  included  in  any 
contract  without  full  agreement  on  cost,  schedule,  and 
technical  adjustments.  If  it  is  not  possible  to  reach  an 
agreement  on  cost  before  work  starts,  a  ceiling  price  should 
be  included  in  the  contract  modification  to  cover  the 
changed  work. 
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o  Be  extremely  careful  not  to  make  constructive  changes  to 
contracts.  Constructive  changes  occur  when  a  person  in 
authority  other  than  the  CO  directs  a  contractor  to  do 
something  outside  the  scope  of  the  contract.  Once 
performed,  the  contractor  can  bill  the  Government  for  all 
associated  costs.  Such  changes  are  often  used  by 
contractors  to  "get  well"  on  projects  that  are  experiencing 
cost  and  schedule  overruns.  All  changes  to  a  contract  must 
be  implemented  by  the  CO  after  cost,  supportability  and/or 
schedule  impacts  are  agreed  to  by  the  Government  and  the 
contractor . 

o  Changing  contracts  after  award  is  very  costly  and  usually 
delays  the  program.  Generally,  major  configuration  changes 
should  be  introduced  at  the  beginning  of  production  to  avoid 
re-work  and  change  to  an  existing  contract.  "Work  around" 
efforts  to  get  a  project  back  on  schedule  are  rarely 
successful,  even  when  significant  additional  funds  are  added 
to  accelerate  the  process.  Where  changes  reduce  contract 
requirements,  the  Contracting  Officer  is  required  to  obtain 
consideration  from  the  contractor. 

o  Interface  issues  have  caused  major  problems  on  NAS  programs. 
The  FAA  has  awarded  contracts  with  equipment  interfaces 
either  partially  defined  or  with  interfaces  to  be  defined 
later,  especially  when  other  equipment  requiring  an 
interface  is  also  being  developed.  Since  defining 
interfaces  after  award  requires  a  contract  change  that 
usually  extends  delivery  schedules  and  increases  cost, 
interfaces  should  be  defined  as  completely  as  possible  at 
the  time  of  contract  award.  If  interfaces  cannot  be 
completely  defined,  funding  should  be  reserved  to  cover 
probable  cost  increases,  and  management  attention  should  be 
focused  on  this  issue  throughout  the  acquisition. 

o  Schedule  slippage  is  often  caused  by  problems  resulting  from 
poor  quality.  Most  quality  problems  are,  in  turn, 
associated  with  poor  definition  of  requirements,  poor 
engineering,  or  inadequate  testing.  Additional  efforts  in 
the  requirements/specifications  development  process  and  at 
preliminary  and  critical  design  reviews  usually  pay  high 
dividends  with  respect  to  achieving  a  higher  quality 
product.  Poor  engineering  is  almost  always  obvious  at 
preliminary  design  review  (PDR)  and  critical  design  review 
(CDR) .  PMs  sometimes  allow  contractors  to  proceed  before 
these  PDR/CDR  problems  are  fixed.  Such  actions  to  keep  a 
project  on  schedule  usually  end  up  causing  much  greater 
slippage  later  in  the  program. 

o  Protests  occur  on  many  competitive  contract  actions.  Most 
are  not  justified  and  are  rejected.  To  provide  for  the 
FAA' s  defense,  selection  procedures  must  be  followed  exactly 
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as  set  forth  in  the  approved  selection  plan.  Adequate 
documentation  must  be  maintained  during  the  evaluation 
process  to  record  how  judgements  are  made.  This 
documentation  is  needed  by  the  FAA  legal  staff  to  defend 
against  possible  protests.  (In  some  cases,  support 
contractors  involved  in  the  pre-award  technical  evaluation 
of  a  procurement  have  been  reluctant  to  support  the  FAA  in 
protests  unless  pressure  was  applied) .  Support  contractors 
that  assist  in  conducting  technical  evaluations  should  have 
a  SOW  requirement  in  their  contract  requiring  them  to  assist 
the  FAA  in  the  event  of  a  protest. 

o  Significant  time  is  lost  in  the  procurement  process  by 

failure  of  the  program  office  to  develop  clear,  tailored 
statements  of  work  and  specifications  before  submitting  the 
procurement  request.  The  CO  and  contracting  staff  should  be 
involved  when  the  procurement  request  is  being  developed  and 
draft  documents  released  for  industry  review  and  comment . 

o  Effective  contract  administration  is  necessary  to  obtain  a 
product  that  satisfies  Government  requirements.  Adequate 
contract  administration  can  avoid  claims  or  loss  of  legal 
rights  that  occur  when  actions  required  by  the  contract  have 
not  been  taken. 

o  Contract  administration  must  be  considered  when  structuring 
the  solicitation.  Generally,  simple  and  straightforward 
contract  provisions  are  the  easiest  to  administer  and 
change.  Many  contracts  have  scores  of  modifications  over 
their  life,  and  complex  provisions  are  subject  to  dispute, 
especially  when  changed.  The  courts  have  generally  held 
that  the  Government,  as  the  author  of  the  contract,  is 
responsible  for  providing  clear,  unambiguous  terms  and 
conditions  within  the  contract . 

o  Priced  options  should  be  included  in  all  competitive 

production  contracts  to  the  maximum  extent  possible  so  FAA 
can  obtain  the  best  prices  for  possible  new  requirements 
that  may  arise  during  the  life  of  the  contract.  "Possible" 
is  defined  as  any  potential  requirement  relative  to  the 
procurement  that  has  some  historic  precedent .  Option 
provisions  can  eliminate  the  need  for  new  contracts, 
including  sole-source  extensions  of  existing  contracts. 

o  Proper  contractor  staffing  at  the  beginning  of  a  project  is 
essential.  Manpower  or  critical  skill  shortages  during  the 
initial  design  phase  usually  result  in  schedule  delays  and 
cost  increases  later  on.  PMs  must  consistently  compare 
planned  manpower  and  material  cost  against  actual  cost  to 
verify  that  adequate  resources  are  being  applied. 
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o 


The  QRO  is  a  valuable  asset  in  the  program.  Since  this 
officer  is  "in  plant",  he/she  should  be  part  of  all 
program/contract  reviews  to  keep  the  PM  informed  about 
programs,  problems,  factory  issues  (e.g.,  lack  of  staff, 
potential  labor  unrest),  etc.  However,  quality  can't  be 
"inspected  in"  after  the  equipment  is  built.  It  must  be 
planned  right  from  the  start . 

o  A  contract  type  that  matches  the  need  for  flexibility  should 
be  used 

o  ASU  should  be  involved  in  draft  reviews  of  the  PR  package, 
including  the  Statement  of  Work,  specifications,  data 
requirements,  and  other  sections  and  not  see  it  for  the 
first  time  when  the  PR  is  officially  received 

Contacts 

The  following  groups  can  be  contacted  for  additional  information 

on  the  issues  presented  in  this  chapter: 


o 

AND-3, 

202-267-8218 

o 

ACQ-1, 

202-267-8506 

o 

ASU-1, 

202-267-8513 

Point  of  Contact  for  Chapter  22  is  Robert  Bernard,  ANN-600, 
202-267-6511  . 
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Acronyms  And  Abbreviations 


AAC 

AAF 

AAP 

AAS 

AAT 

ABA 

ABU 

ACD 

ACF 

ACN 

ACQ 

ACT 

ACW 

ADA 

ADDS 

ADP 

ADPE 

AF 

AFE 

AFS 

AFSS 

AGC 

AHR 

AHT 


Mike  Monroney  Aeronautical  Center 

Associate  Administrator  for  Airway  Facilities 

Program  Manager  for  Advanced  Automation 

Advanced  Automation  System 

Associate  Administrator  for  Air  Traffic 

Assistant  Administrator  for  Budget  and  Accounting 

Office  of  Budget 

Engineering  Research  and  Development  Service 
Area  Control  Facility 

Engineering,  Test  and  Evaluation  Service 
Office  of  Acquisition  Policy  and  Oversight 
FAA  Technical  Center 

Engineering,  Integration,  and  Operational  Evaluation 
Service 

FAA  Deputy  Administrator 
Aeronautical  Data  Link  System 
Automated  Data  Processing 
Automated  Data  Processing  Equipment 
Airway  Facilities 

Facility  System  Engineering  Service 
Flight  Standards  Service 
Automated  Flight  Service  Station 
FAA  Chief  Counsel 

Assistant  Administrator  for  Human  Resource  Management 
Office  of  Training  and  Higher  Education 
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AIT 

ALM 

ALR 

AMA 

ANA 

ANC 

AND 

ANFCCB 

ANN 

ANR 

ANS 

ANW 

AOA 

AOP 

AOR 

AOS 

AP 

APM 


Office  of  the  Assistant  Administrator  for  Information 
Technology 

Life-Cycle  Management  Service 
Office  of  Labor  and  Employee  Relations 
FAA  Academy 

Program  Director  for  Automation 

Program  Director  for  Communications  and  Aircraft 

Acquisition 

Associate  Administrator  for  NAS  Development 

NAS  Facilities  Configuration  Control  Board 

Program  Director  for  Navigation  and  Landing 

Program  Director  for  Surveillance 

NAS  Transition  and  Implementation  Service 

Program  Director  for  Weather  and  Flight  Service  Systems 

FAA  Administrator 

NAS  Operations  Service 

Operations  Research  Service 

Operational  Support  Service 

Acquisition  Plan 

Associate  Program  Manager,  or  NAS  Program  Management 
Service 


APMC 

APME 

APMGC 

APML 

APMM 

APMP 

APMQ 


Associate  Program  Manager  for 
Associate  Program  Manager  for 
Associate  Program  Manager  for 
Associate  Program  Manager  for 
Associate  Program  Manager  for 
Associate  Program  Manager  for 
Associate  Program  Manager  for 


Contracting 

Engineering 

Legal 

Logistics 

Operations 

Procedures 

Quality 


B-3 


APMR 

APMRD 

APMSE 

APMT 

APR 

ARC 

ARD 

ARSR 

ARTCC 

ARTS 

ASD 

ASDE 

ASE 

ASM 

ASR 

ASU 

AT 

ATC 

ATCT 

ATH 

ATQ 

ATR 

ATZ 

AVN 

AWPG 


Associate  Program  Manager  for  Requirements 

Associate  Program  Manager  for  Research  and  Development 

Associate  Program  Manager  for  System  Engineering 

Associate  Program  Manager  for  Testing 

Agency  Procurement  Request 

Acquisition  Review  Committee 

Research  and  Development  Service 

Air  Route  Surveillance  Radar 

Air  Route  Traffic  Control  Center 

Automated  Radar  Terminal  System 

Associate  Administrator  for  Systems  Engineering  and 
Development 

Airport  Surface  Detection  Equipment 

NAS  System  Engineering  Service 

System  Maintenance  Service 

Airport  Surveillance  Radar 

Office  of  Acquisition  Support 

Air  Traffic 

Air  Traffic  Control 

Airport  Traffic  Control  Tower 

Office  of  Air  Traffic  System  Effectiveness 

Office  of  Independent  Operational  Test  and  Evaluation 
Oversight 

Air  Traffic  Requirements  Service 
Office  of  Air  Traffic  Program  Management 
Office  of  Aviation  System  Standards 
Aviation  Weather  Products  Generator 
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AXD 

AXQ 

BAFO 

BUEC 

CAI 

CASE 

CBA 

CCB 

CDR 

CDRL 

CHAP 

Cl 

CIP 

CM 

CNS 

CO 

COI 

CONOPS 

CONT 

COR 

COTR 

COTS 

CSQPP 

CWP 

DBMS 

DD 


Executive  Director  for  Systems  Development 

Executive  Director  for  Acquisition  and  Safety  Oversight 

Best  and  Final  Offer 

Backup  Emergency  Communications 

Contract  Acceptance  Inspection 

Computer-Aided  Software  Engineering 

Cost/Benefit  Analysis 

Configuration  Control  Board 

Critical  Design  Review 

Contract  Data  Requirements  List 

Chapter 

Configuration  Item 
Capital  Investment  Plan 
Configuration  Management 

Communications,  Navigation,  and  Surveillance 

Contracting  Officer 

Critical  Operational  Issues 

Concept  of  Operations 

Continued 

Contracting  Officer's  Representative 

Contracting  Officer's  Technical  Representative 

Commercial  Of f-the-Shelf 

Computer  Software  Quality  Program  Plan 

Central  Weather  Processor 

Data  Base  Management  System 

Design  Document 


B-5 


DFP 


Detailed  Financial  Plan 


DID  Data  Item  Description 

DIR  Directive 

DLP  Data-Link  Processor 

DMN  Data  Multiplexing  Network 

DOCCON  Documentation  and  Configuration  Identification  System 

DOD  Department  of  Defense 

DOT  Department  of  Transportation 

DPA  Delegation  of  Procurement  Authority 

DRR  Deployment  Readiness  Review 

DSO  Designated  Senior  Official 

DT&E  Developmental  Test  and  Evaluation 

EBBS  Electronic  Bulletin  Board  System 

ECP  Engineering  Change  Proposal 

EM  Element  Manager 

ERB  Executive  Review  Board 

ERC  Executive  Resource  Committee 

EXCOM  Executive  Committee 

FAA  Federal  Aviation  Administration 

FAR  Federal  Acquisition  Regulation 

FBCN  Financial  Baseline  Change  Notice 

FCA  Functional  Configuration  Audit 

F&E  Facilities  and  Equipment 

FIP  Federal  Information  Processing 

FIRMR  Federal  Information  Resource  Management  Regulation 

FS  Flight  Standards 
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FSAT  Facility  System  Analysis  Tool 

FSD  Full  Scale  Development 

FSR  Financial  Status  Review 

FSS  Flight  Service  Station 

FTE  Full  Time  Equivalent 

FWG  Functional  Working  Group 

FY  Fiscal  Year 

GAO  Government  Accounting  Office 

GIDEP  Government  Industry  Data  Exchange  Program 

GSA  General  Services  Administration 

GTR  Government  Technical  Representative 

HDBK  Handbook 

HF  Human  Factors 

HFE  Human  Factors  Engineering 

HFP  Human  Factors  Plan 

HVAC  Heating,  Ventilating,  and  Air  Conditioning 

HWCI  Hardware  Configuration  Item 

ICD  Interface  Control  Document 

less  Integrated  Communications  Switching  System 

ICWG  Interface  Control  Working  Group 

IG  Inspector  General 

ILS  Integrated  Logistics  Support 

ILSP  Integrated  Logistics  Support  Plan 

INST  Instruction 

lOT&E  Independent  Operational  Test  and  Evaluation 
IR  Interface  Revision 
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IRD 

IRM 

ITWS 

JOTFOC 

KDM 

KDP 

KMOR 

LCC 

LCF 

LDRCL 

LOG 

LSA 

MA 

MAR 

MCF 

ME 

MIL 

MLS 

MNA 

MNAT 

MNS 

MSA 

MSS 

MTP 

N/A 

NAATS 


Interface  Requirements  Document 
Information  Resource  Management 
Integrated  Terminal  Weather  System 

Justification  for  Other  than  Full  and  Open  Competition 
Key  Decision  Memorandum 
Key  Decision  Point 

Key  Measures  of  Operational  Readiness 

Life  Cycle  Cost 

Local  Control  Facility 

Low  Density  Radio  Communications  Link 

Lines  of  Code 

Logistics  Support  Analysis 
Major  Acquisition 
Major  Acquisition  Review 
Metroplex  Control  Facility 
Maintenance  Engineering 
Military 

Microwave  Landing  System 
Mission  Needs  Analysis 
Mission  Needs  Analysis  Team 
Mission  Need  Statement 
Major  System  Acquisition 
Master  Scheduling  System 
Master  Test  Plan 
Not  Applicable 

National  Association  of  Air  Traffic  Specialists 


B-8 


NADIN 


NAGE 

NAILS 

NAILSMT 

NAS 

NASA 

NAS  CCB 

NATCA 

NCF 

NCP 

NDI 

NO 

NOAA 

NPI 

OIRM 

OJT 

0MB 

OPMT 

OPS 

ORD 

OST 

OT&E 

PA 

PASS 

PAT&E 

PCA 


National  Airspace  Data  Interchange  Network 
National  Association  of  Government  Employees 
National  Airspace  Integrated  Logistics  Support 
NAILS  Management  Team 
National  Airspace  System 

National  Aeronautics  and  Space  Administration 

NAS  Configuration  Control  Board 

National  Air  Traffic  Controllers  Association 

National  Control  Facility 

NAS  Change  Proposal 

Nondevelopmental  Item 

Number 

National  Oceanic  and  Atmospheric  Administration 
NAS  Program  Initiative 

Office  of  Information  Resource  Management 

On-The-Job  Training 

Office  of  Management  and  Budget 

Operational  Planning  Management  Team 

Operations 

Operational  Requirements  Document,  or  Operational 
Readiness  Date 

Office  of  the  Secretary  of  Transportation 
Operational  Test  and  Evaluation 
Project  Authorization 

Professional  Airways  Systems  Specialists 
Production  Acceptance  Test  and  Evaluation 
Physical  Configuration  Audit 
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PD 


Program  Directive 
PDR  Preliminary  Design  Review 

PDSR  Program  Director  Status  Review 

PEM  Production  Engineering  Management 

PIP  Program  Implementation  Plan 

PM  Program  Manager 

PMP  Program  Master  Plan 

POV  Privately  Owned  Vehicle 

PR  Procurement  Request 

PRR  Procurement  Readiness  Review,  or  Program  Readiness 

Review 

PSAT  Power  System  Analysis  Tool 

QA  Quality  Assurance 

Q&A  Questions  and  Answers 

QAS  Quality  Assurance  Specialist 

QC  Quality  Control 

QCSP  Quality  Control  System  Plan 

QRO  Quality  Reliability  Officer 

QTR  Quarter 

RAS  Resource  Allocation  Subcommittee 

RCE  Radio  Control  Equipment 

RCL  Radio  Communications  Link 

RCR  Routing  and  Circuit  Restoral 

R&D  Research  and  Development 

R,  E&D  Research,  Engineering  and  Development 

RFI  Radio  Frequency  Interference 

RFP  Request  for  Proposal 
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RMA 


Reliability,  Maintainability  and  Availability 
RMP  Risk  Management  Plan 

RPI  Research  Project  Initiative 

RTG  Routing 

SAMP  Software  Acquisition  Management  Plan 

SBA  Small  Business  Administration 

SC  Steering  Committee 

SCE  Software  Capability  Evaluation 

SCR  Schedule  Change  Request 

SDP  Software  Development  Plan 

SE  System  Engineering 

SEB  Source  Evaluation  Board 

SEBOB  SEB  Oversight  Board 

SE  CCB  System  Engineering  Configuration  Control  Board 

SE&D  System  Engineering  and  Development 

SEI/  System  Engineering  and  Integration  (Contractor) 

SEIC 

SEOAT  System  Engineering/Operational  Analysis  Team 

SESG  Software  Engineering  Specialty  Group 

SETA  System  Engineering  and  Technical  Assistance 

SIWG  Software  Interface  Working  Group 

SLSR  Senior  Level  Status  Review 

SOP  Standard  Operating  Procedure 

SOW  Statement  of  Work 

SPEC  Specification 

SR  System  Requirement 

SRB  Specification  Review  Board 
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SRS 

SS 

STD 

STVS 

TAM 

TATCA 

TDWR 

T&E 

TEMP 

TIM 

TMS 

TOR 

TPRC 

TRACON 

TRDRE 

TSARC 

TVSR 

USAF 

VRTM 

VSCS 

WBS 


System  Requirements  Specification 

System  Specification 

Standard 

Small  Tower  Voice  Switches 

Transportation  Acquisition  Manual 

Terminal  Air  Traffic  Control  Automation 

Terminal  Doppler  Weather  Radar 

Test  and  Evaluation 

Test  and  Evaluation  Master  Plan 

Technical  Interchange  Meeting 

Traffic  Management  System 

Technical  Officer's  Representative 

Test  Policy  Review  Committee 

Terminal  Radar  Approach  Control 

Terminal  Radar  Digitizing,  Replacement,  and 
Establishment 

Transportation  Systems  Acquisition  Review  Council 
Terminal  Voice  Switch  Replacement 
United  States  Air  Force 

Verification  Requirements  Traceability  Matrix 
Voice  Switching  and  Control  System 
Work  Breakdown  Structure 
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APPENDIX  C 


LIST  OF  DOCUMENTS 
PROCEDURES  FOR  OBTAINING 
COPIES  OF  DOCUMENTS 


List  Of  Dociiments 


This  listing  includes  not  only  those  documents  used  in  the 
various  chapters  of  the  Program  Manager's  Guide,  but  other 
documents  recommended  for  background  reading  by  the  authors  of 
the  guide. 

The  NAS  Documentation  and  Configuration  Identification  System 
{DOCCON)  is  a  document  storage  facility  which  is  located  in  the 
World  Trade  Center  building.  Copies  of  most  of  the  documents 
listed  in  this  appendix  may  be  obtained  from  this  facility. 
There  are  several  procedures  for  using  this  facility  and  these 
are  described  at  the  end  of  the  document  listing. 


FAA  Order  1100. 2C,  Organization  -  FAA  Headquarters 
FAA  Order  1320. ID,  FAA  Directives  System 

FAA  Order  1370. 52C,  Information  Resources  Management  -  Policies 
and  Procedures 

FAA  Order  1370.71,  Procurement  Authority  for  Information 
Resources  and  ADP 

FAA  Order  1600. 54B,  FAA  Automated  Information  Systems  Security 
Handbook 

FAA  Order  1800. 8F,  NAS  Configuration  Management 

FAA  Order  1800. 57A,  Establishment  of  the  National  Airspace  System 
(NAS)  Configuration  Control  Board  (CCB) 

FAA  Order  1800. 58A  (Draft),  National  Airspace  Integrated 
Logistics  Support  (NAILS)  Policy 

FAA  Order  1800.63,  National  Airspace  System  (NAS)  Deployment 
Readiness  Review  (DRR)  Program 

FAA  Order  1810.  IF,  FAA  Acquisition  Policy 

FAA  Order  1810.2,  Independent  Operational  Test  and  Evaluation  for 
Major  Systems  Acquisition 

FAA  Order  1810. 4B,  NAS  Test  and  Evaluation  Program 

FAA  Order  1810.6,  Policy  For  the  Use  of  Nondevelopmental  Items 
(NDI)  in  FAA  Acquisitions 

FAA  Order  1810. X  (Draft),  Acquisition 
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FAA  Order  1830. 2B,  Telecommunications  Standards  Selection  and 
Implementation  Policy 

FAA  Order  2500. lOR,  Operations  Appropriation  Call  for  Estimates 

FAA  Order  2500. 22X,  Call  for  Estimates  -  R, E&D  Appropriation 

FAA  Order  2500.55,  Call  for  Estimates  -  Facilities  and  Equipment 

FAA  Order  3710. 7C,  Labor  Management  Relations  Program 

FAA  Order  WA  4400.1,  Guide  for  Preparing  Procurement  Requests 

FAA  Order  4405. 6B,  Review  and  Approval  of  Proposed  Other  Than 
Full  and  Open  Competition  Procurements 

FAA  Order  4405.15,  Reprocurement  Data  Acquisition  Policy 

FAA  Order  4453. lA,  Quality  Assurance  of  Material  Procured  by  FAA 

FAA  Order  4453. 2B,  FAA  Quality  Control  System  Certification 
Program 

FAA  Order  4470.1,  FAA  Participation  in  GIDEP 

FAA  Order  4560. IB,  Policies  and  Procedures  Covering  the 
Provisioning  Process  During  the  Acquisition  of  FAA  Materiel 

FAA  Order  4630.8,  Quality  Assurance  Policy 

FAA  Order  4630. 9A,  FAA  Computer  Software  Quality  Program 
Requirements 

FAA  Order  6000. 30B,  Policy  for  Maintenance  of  the  National 
Airspace  System  (NAS)  Through  the  Year  2000 

FAA  Order  6000.38,  Policy  to  Determine  NAS  Equipment  Sparing 
Requirements  for  Airway  Facilities  Work  Center 

FAA  Order  9550.8,  Human  Factors  Policy 

FAA  Notice  1810.2,  Procurement  Readiness  Review  (PRR)  Process 

FAA  Notice  1370.36,  NAS  Programming  Language  Procedure  {Ada 
Policy) 

FAA  Form  1800-2,  NAS  Change  Proposal  Form 

DOT  Order  1350.2,  Establishment  of  a  Departmental  Information 
Resources  Management  Manual  System 

DOT  Order  4200. 14C,  Major  Acquisitions 


DOT  Order  4200. 16A,  Advance  Acquisition  Planning  and  Annual 
Procurement  Plan 

FAA-STD-002,  Preparation  of  Engineering  Drawings 
FAA-STD-005,  Preparation  of  Specification  Documents 
FAA-STD-013,  Quality  Control  Program  Requirements 
FAA-STD-016A,  Quality  Control  System  Requirements 
FAA-STD-018,  Computer  Software  Quality  Program  Requirements 
FAA— STD-021,  Configuration  Management  (Contractor  Requirements) 
FAA-STD-024,  Preparation  of  T&E  Documentation 
FAA-STD-025,  Preparation  of  ICDs 
FAA-STD-026,  NAS  Software  Development 

FAA-STD-029,  Selection  and  Implementation  of  Telecommunications 
Standards 

FAA-STD-035,  Commercial  Equipment,  Market  Research  for 
FAA-STD-039,  NAS  Open  System  Architecture  and  Protocols 
FAA-G-1210d,  Provisioning  Technical  Documentation 

FAA-G-1375C,  Spare  Part s-Peculiar  for  Electronic,  Electrical,  and 
Mechanical  Equipment 

FAA-G-2100F,  Electronic  Equipment,  General  Requirements 

FAA-HDBK-XXX  (Draft) ,  FAA  Software  Management  Indicators  Handbook 

FAA-HDBK-***  (Draft),  NAS  Tailoring  Guide  for  FAA-STD-026 

NAS-DD-1000,  NAS  Level  I  Design  Document 

NAS-MD-001,  NAS  Subsystem  Baseline  Configuration  and 
Documentation  Listing 

NAS-MD-110,  T&E  Terms  and  Definitions  for  NAS 
NAS-SR-1000,  NAS  System  Requirements  Specification 
NAS-SS-1000,  NAS  System  Specification 
Capital  Investment  Plan  (CIP) 
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Research,  Engineering  and  Development  (R,E&D)  Plan 

Business  Manager's  Financial  Handbook,  published  October  1992  (to 
be  updated  in  the  May  1994  timeframe) 

FAA  Capital  Investment  Planning  Process  for  FY  1996,  September 
1993 

Annual  Procurement  Plan 

Advance  Acquisition  Plans 

Financial  Management  System 

Software  Management  Indicators  Handbook 

Advisory  Circular  00-41,  FAA  Quality  Control  System  Certification 
Program 

Advisory  Circular  00-53,  FAA  Computer  Software  Quality  Program 
1993  NATCA/FAA  negotiated  agreement,  Articles  7  and  48 

1992  PASS  (AF*) /FAA  negotiated  agreement.  Articles  69  and  70 

1993  NAATS/FAA  negotiated  agreement,  Article  9 

1993  PASS (FS) /FAA  negotiated  agreement,  Articles  68  and  69 

DOT/FAA/ES-85/01 ,  NAS  Interface  Management  Plan 

CCB  Charters  and  Operating  Procedures  -  Charters  and  Operating 
Procedures  for  program  CCBs  (acquisitions)  ,  regional  CCBs,  the  AT 
CCB,  and  the  ME  CCB 

Guidance  and  Implementation  Planning  for  the  Conduct  of  Formal 
Configuration  Audits,  Revision  5,  dated  January  29,  1988  - 

Guidelines  published  by  SEIC  for  ASE-3.2  for  planning  and 
conducting  of  PCAs  and  FCAs 

Configuration  Management  Procurement  Guidance,  Revision  4,  dated 
October  26,  1989  -  Guidelines  published  by  SEIC  for  ASE-3.2  for 
the  application  of  FAA-STD-021  on  project  acquisition  contracts 

"Source  Selection  Delegation",  memorandum  from  the  Secretary  of 
Transportation  to  the  Administrator,  dated  December  20,  1987 

Guide  to  the  Preparation  of  Agency  Procurement  Requests  (AIT 
publication) ,  dated  February  1994 

FAA  Acquisition  Manual  Subchapter  1204.70,  Preparation,  Approval 
and  Processing  of  Procurement  Requests 
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Transportation  Acquisition  Regulation,  sub-part  1206.3 

Transportation  Acquisition  Manual  (TAM)  Chapter  34,  Appendix  A, 
Major  Acquisition  Policies  and  Procedures 

Transportation  Acquisition  Manual,  Sub-chapter  1215.6,  Source 
Selection 

Air  Force  Systems  Command  Regulation  84-2,  Production  Readiness 
Review 

0MB  Circular  A-11 

0MB  Circular  A-109,  Major  Systems  Acquisition 
0MB  Bulletin  93-03 

DOD-DIR-4245 . 6 ,  Defense  Production  Management 

DOD-DIR-5000 . 1,  Major  Systems  Acquisitions 

DOD-DIR-5000 . 39,  Acquisition  and  Management  of  Integrated 
Logistics  Support  for  Systems  and  Equipment 

DOD-DIR-5010 . 19,  DOD  Configuration  Management  Program 

DOD-INST-5000 . 2M,  Major  Systems  Acquisition  Procedures 

DOD-INST-5000 . 38,  Production  Readiness  Reviews 

DOD-lNST-7000 . 2,  Performance  Measurement  for  Selected 
Acquisitions 

DOD-INST-7000 . 10,  Contract  Cost  Performance,  Funds  Status  and 
Cost /Schedule  Status  Reports 

DOD-STD-4 8 OA,  Configuration  Control 

DOD-STD-481A,  Configuration  Control  Engineering  Changes 

DOD-STD-1686,  Electrostatic  Discharge  Control  Program 

DOD-STD-2167A,  Defense  System  Software  Development 

MIL-H-46855,  Human  Engineering  Requirements  for  Military  Systems, 
Equipment,  and  Facilities 

MIL-STD-499,  Engineering  Management 

MIL-STD-882B,  System  Safety  Program  Requirements 

MIL-STD-965A,  Parts  Control  Program 
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MIL-STD-973,  Configuration  Management,  Paragraph  5.5 
Configuration  Status  Accounting,  and  Paragraph  5.6  Configuration 
Audits 

MIL-STD-1388-1A,  Logistics  Support  Analysis 

MIL— STD-1388-2A/2B,  DOD  Requirements  for  Logistics  Support 
Analysis  Record 

MIL-STD-1472,  Human  Engineering  Design  Criteria  for  Military 
Systems,  Equipment,  and  Facilities 

MIL-STD-152 IB,  Technical  Reviews  and  Audits  for  Systems, 
Equipment,  and  Computer  Programs 

MIL-STD-1561B,  Provisioning  Procedures 

MIL-STD-1815A,  ADA  Programming  Language 

MIL-STD-2000,  Standard  Requirements  for  Soldered  Electrical  and 
Electronic  Assemblies 

MIL-HDBK-287,  Tailoring  Guide  for  DOD-STD-21 67A,  Defense  System 
Software  Development 

DI-MCCR-80030A 

RTCA  DO-17 8B 

Software  Management  Indicators  Handbook 

Federal  Information  Resource  Management  Regulation  (FIRMR) 

Federal  Service  Labor-Management  Relations  Statute,  5  U.S.C. 
Chapter  71 

Federal  Acquisition  Regulation,  sub-part  6.3 
Federal  Acquisition  Regulation  34.001 
Federal  Acquisition  Regulation  52.246-2 

Federal  Acquisition  Quality  Assurance  Regulation,  Part  46 
Budget  Enforcement  Act  of  1990 

Streamlining  Defense  Acquisition  Laws,  Report  of  the  Acquisition 
Law  Advisory  Panel  to  the  United  States  Congress,  January  1993 
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Procedures  For  Obtaining  Copies  Of  These  Documents 


There  are  presently  three  ways  in  which  to  request  copies  of  the 

documents  listed  in  this  appendix. 

1.  Fill  out  a  document  request  form  at  the  Documentation 
Control  Center.  There  is  no  limit  to  the  number  of 
documents  that  can  be  requested,  but  no  more  than  two  copies 
of  each  document  will  be  provided.  The  PM  is  responsible 
for  making  further  copies  if  needed.  The  turnaround  time 
for  this  procedure  is  2-3  days.  The  bookshelf  on  the  right 
just  inside  the  entrance  to  the  Center  holds  the  requested 
copies  for  pickup.  Each  request  and  its  accompanying 
documents  are  placed  on  the  bookshelf  in  alphabetical  order 
using  the  last  name  of  the  person  requesting  the  copies. 

2.  Fill  out  a  Document  Request  Form.  (There  is  one  on  page  D- 
9) .  Only  five  documents  may  be  requested  at  any  one  time, 
and  no  more  than  two  copies  of  each  document  will  be 
provided.  The  PM  is  responsible  for  making  further  copies 
if  needed.  This  form  can  then  be  sent  through  the  mail  to 
the  Documentation  Control  Center,  ASE-621,  or  faxed  to  the 
center  on  FTS  967-2094.  In  both  instances,  address  the 
request  to  the  attention  of  Anne  Rutemiller.  (A  sample  fax 
from  a  regional  center  is  located  at  the  end  of  this 
appendix.)  The  turnaround  time  for  this  procedure  is 
approximately  3-5  days  for  headquarters,  and  15  days  for 
regional  offices.  The  RUSH  service  is  available  for 
emergency  use  only. 

3.  The  optimum  request  procedure  involves  obtaining  a  DOCCON 
User  ID.  This  will  enable  the  PM  to  access  the  DOCCON 
computer  data  base  directly  (in  many  instances  from  a 
personal  computer)  to  order  the  documents .  The  turnaround 
time  for  this  procedure  is  usually  1-2  days.  Occasionally, 
a  requested  document  exists  only  on  microfiche.  If  so,  the 
Documentation  Control  Center  will  notify  the  PM  and  the 
turnaround  time  may  be  a  little  longer  while  the  microfiche 
is  copied  or  supplied. 

The  procedure  for  obtaining  a  DOCCON  User  ID  is  as  follows: 

o  Fill  out  a  Resource  Access  Authorization  Request  Form 
(There  is  one  at  the  end  of  this  appendix) 

o  Get  requisite  approval  signatures  from  the  appropriate 
FAA  personnel 

o  Send  the  form  to  the  Documentation  Control  Center,  c/o 
Ms.  Mary  Anne  Spicer 
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When  the  PM  receives  his/her  User  ID,  he/she  will  also  receive  a 
copy  of  the  DOCCON  Program  Control  Tool  General  User' s  Reference 
Guide  which  explains  the  DOCCON  computer  process.  Personnel  at 
the  Documentation  Control  Center  will  assist  in  answering 
questions  and  providing  on-the-spot  guidance  until  the  copy 
request  process  becomes  familiar. 

One  menu  selection  on  DOCCON  allows  access  to  the  listing  of 
documents  that  are  contained  in  the  system.  There  is  also  a 
hardcopy  listing  which  is  available.  A  monthly  update  to  this 
hardcopy  listing  is  distributed  to  FAA  division-level  managers. 
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Docxunent  Request  Form 


From  the  Martin  Marietta  Air  Traffic  Systems  Documentation 
Control  Center 

DATE: 

TO:  Anne  Rutemiller,  Documentation  Control  Center 

FROM: 

RE:  Photocopy  of  Documentation 

Please  send  _  copy(s)  of  the  following  documents: 


Signature 
Routing  Address : 
Telephone  Number : 
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Sample  Fax  From  A  Regional  Office 


FAA,  Northwest  Mountain  Region 

New  Denver  International  Airport  Project  Office 


DATE: 

November  16,  1991 

TO: 

Anne  Rutemiller 

ROUTING: 

FTS 

967-2094 

FROM: 

ROUTING: 

ANM- 

■458E2 

(206)  227-1366 


Request  the  following  documents: 

TI  6560.18,  New  Generation  RVR-FA-10268  Offsite  Instruction  Book 


Send  To:  Federal  Aviation  Administration 
ANM-458E2 

1601  Lind  Avenue,  SW 
Renton,  WA  98055-4056 
FTS  392-1366 


C-11 


APPLICANT : 


ATC  Computer  Center  Form  1-1 
Resource  Access  Authorization  Request 


Company : 

FAA/ _ _ _ 

Applicant  Name:  First  _  _  _  MI  Last 

Mail  Point:  _ _ZZIZZZ _ 

Address : 


Telephone  Number:  _ 

INITIAL  REQUEST  _  CHANGE  REQUEST 

TOOL  NAME  ACCESS 

DOCCON  SYSTEM  ATC 

PURPOSE/USE  (BRIEF  DESCRIPTION) 

General  user  access  to  query/retrieve  information;  place  document 
orders  online. 

AWO  NUMBER  (IF  KNOWN)  _ 


Applicant  Manager' s  Signature/Date 


Applicant  Signature 

CERTIFICATION  (BY  MARTIN  MARIETTA) 

I  certify  and  approve  the  above  request.  The  requestor  has  been 
briefed  as  to  the  prohibition  of  using  terminals  for  processing 
Government  classified  information  and  the  requirement  to  protect 
the  confidentiality  of  logon/signon  passwords  and  report  any 
compromises  of  such  passwords.  I  agree  to  have  the  user's 
logon/signon  password  changed  immediately  if  compromised.  I  will 
notify  Martin  Marietta  ATC  Computer  Center's  RACF  Administrator 
if  the  requestor's  employment  status  changes,  or  if  the  employee 
has  no  further  need  for  the  above  requested  item. 


FAA  Approval  (As  required) 

TO  BE  COMPLETED  BY  ATC  COMPUTER  CENTER 

Application  ATC  ID  Number  Initial  Password 
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